Install and enable

Activating Hummingbot Connector — the Ecosystem prerequisite, the two tables it creates, seventeen permission keys, the seeded strategy presets, where the supervisor runs, and a four-command smoke test.

5 min readUpdated 3 August 2026install, ecosystem, permissions, licence, smoke-test

Activation itself takes a minute. What takes longer is proving the engine underneath it is real, because this addon owns no order book and an install with no tradable market looks completely healthy right up until a bot connects and waits forever.

Before you activate

Bicrypto core installed and running — see Installing Bicrypto
The ecosystem extension activated at /admin/system/extension
At least one active ecosystem market with resting orders on it
Redis reachable — nonce replay protection and rate-limit counters live there
The futures extension, only if you want perpetual trading
Hummingbot v2 from source, in a conda environment, on whichever machine will run a bot

Without Ecosystem the addon still installs, still shows its menus and still issues API keys — and every spot call returns a clean 503 because there is no engine behind it. The same is true of perpetuals without Futures. Neither failure is a misconfiguration you can work around from this addon's settings.

Activation

Buy and download the addon — note the CodeCanyon username and purchase code. The item id is 35988084; the extension registers itself under the name hummingbot.
Open Admin → System → Extensions at /admin/system/extension, click the Hummingbot Connector entry, enter your username and licence code, and confirm.
Restart the backend so the new routes, tables and the instance supervisor are picked up.
```
pnpm updator
```
Confirm the server side answers — this endpoint needs no authentication.
```
curl https://your-domain.com/api/hb/ping
```

Handler sources live under backend/src/api/(ext)/hb/, but parenthesised folders are grouping-only and are stripped from the registered route. Both /api/hb and /api/admin/hb are licence-enforced prefixes, so an expired or unverified licence takes out the whole surface at once rather than one screen.

What activation creates

Two tables of its own:

Table	Holds
`hb_strategy_preset`	Controller presets — family, pair, connectors, parameters, status and version
`hb_instance`	Server-run Hummingbot processes — paths, linked preset and key, desired and actual status, restart counters, last exit

Everything else reuses core tables. API keys are ordinary api_key rows carrying hb:* scopes, and their history is written to api_key_audit_log — which is why disabling a Hummingbot key, rotating its secret and reading its audit trail all behave exactly like every other API key on the platform.

If you build from source, run pnpm types:generate once the tables exist. If you deploy with DB_SYNC=none, run the backend once with sync enabled so the columns and indexes land.

Seeded strategy presets

The Strategy Studio is not empty on a fresh install. Six presets are seeded and published, so they appear to users immediately:

Preset	Family
PMM — Tight (deep, liquid markets)	`pmm`, spot
PMM — Balanced (start here)	`pmm`, spot
PMM — Wide (thin or volatile markets)	`pmm`, spot
PMM — Perpetual, conservative (3x)	`pmm`, perp
XEMM — Hedged on Binance	`xemm`
XEMM — Hedged on MEXC	`xemm`

They are named for market conditions, not pairs, because the market is chosen per deployment and a pair in the name would imply one preset per asset. They are conservative starting points sized for a modest account — set totalAmountQuote to your own size, and recompute the XEMM profitability targets against your own fee schedule, before running any of them.

The seeder only inserts what is missing by name, so editing or deleting a seeded preset is permanent and a later update will not restore it.

Permissions

Seventeen keys ship. Assign them to the roles that should administer the addon at /admin/crm/role.

Key	Grants
`access.hb`	The Hummingbot admin section root at `/admin/hb`
`view.hb.key`	The platform-wide API key registry, its stats and per-key audit trails
`edit.hb.key`	Disabling, re-enabling and setting a per-key rate-limit override
`access.hb.command`	The Command Center screen
`view.hb.command`	The operator list and one operator's live orders and positions
`manage.hb.command`	Force-cancel all of a user's orders, and flatten their positions
`view.hb.instance`	The Bot Instances list, logs, detection, the doctor and the market list
`create.hb.instance`	Registering an instance, provisioning a location, minting a key for it
`edit.hb.instance`	Editing an instance and reinstalling the connector into its checkout
`manage.hb.instance`	Start, stop and restart
`delete.hb.instance`	Deleting an instance
`access.hb.strategy`	The Strategy Studio screen
`view.hb.strategy`	Listing presets and rendering one to YAML
`create.hb.strategy`	Creating a preset
`edit.hb.strategy`	Updating a preset
`delete.hb.strategy`	Deleting presets, singly or in bulk
`access.hb.settings`	The Hummingbot settings screen

Super Admin bypasses permission checks entirely, so an upgrade verified from the owner account tells you nothing. Open /admin/hb as a configured admin role after upgrading and confirm each of the five screens loads.

Saving the settings screen additionally needs edit.settings, because it writes through the platform's own settings endpoint rather than one of this addon's.

The user-facing surface at /hb carries no permissions. Every endpoint there is scoped to the caller's own account. Who may use it is controlled by KYC features instead.

KYC gates

Two independent controls, and they gate different things.

view_hb is a platform KYC feature, configured per level under Admin → CRM → KYC. It guards the strategy preset list, the preset download, the connector kit download, the setup page and the bot console. It only bites when both the platform KYC master switch and per-feature enforcement are on.

hbRequireKyc is this addon's own toggle on its settings screen, off by default, and it gates one thing: creating or rotating a Hummingbot API key. It checks that the user's approved level carries the api_keys feature, falling back to the configured hbRequiredKycLevel while per-feature enforcement is off.

If settings or the KYC tables cannot be read, users are not locked out. The one exception is an unreadable KYC application table while enforcement is explicitly switched on — that reads as unverified, because at that point silently skipping verification is the worse failure.

Where the supervisor runs

The Bot Instances supervisor starts only on the main thread, and only when the hummingbot extension is active. Under the threaded backend entry every worker would otherwise run its own reconciler and spawn a duplicate of each bot — two market makers quoting the same book, neither aware of the other's inventory.

Its failure is deliberately non-fatal: a deployment where the supervisor cannot start still boots and still serves the exchange. Look for this in the log if your server-run bots do not come back after a deploy:

[HB] Hummingbot supervisor not started: <reason>

Smoke test

Four commands answer almost every "is it working" question, and they are the same four to attach to a support ticket.

# 1. Is the server side alive?
curl https://your-domain.com/api/hb/ping

# 2. Is its clock sane? Compare with your own — 10s of drift refuses every request.
curl https://your-domain.com/api/hb/time

# 3. Does the pair you want to quote actually exist and read TRADING?
curl https://your-domain.com/api/hb/exchange-info

# 4. Will `connect bicrypto` appear inside a given checkout?
python hummingbot/install_connectors.py /path/to/hummingbot --doctor

Then, in the panel:

Create a key at /hb/keys with the Spot trading preset. Copy the secret — it is shown once and there is no recovery path, only rotation.
Confirm it appears in the admin registry at /admin/hb, owned by the right account.
Open Strategy Studio at /admin/hb/strategies and confirm the six seeded presets are listed and published.
Open /hb/setup and confirm the base URL it shows is the address a bot should actually dial — it is derived from the incoming request, so it is correct behind a proxy and on a custom domain.

Upgrading

Run pnpm updator, then reinstall the connector into every Hummingbot checkout you control, because the connector packages ship inside the platform:

python hummingbot/install_connectors.py /path/to/hummingbot

Restart the backend afterwards if you run server-side instances, so the supervisor picks up the new build. Read the release notes for the version you are moving to before you compare any admin figure against what you recorded previously — several of them have changed what they count.