Instant delivery

Lifetime updates

1 domain license

Providerv6.1.1

Hummingbot Connector

Name: Hummingbot Connector
Brand: MashDiv
SKU: hummingbot-connector
Price: 169.00 USD
Availability: InStock

Make your platform a venue Hummingbot can trade on — and keep the kill switch in your admin panel.

2 sales

$169$349Launch −52%

Launch pricing−52% right now

This is a new release, so the first 50 customers get it below its normal price of $349. No code needed — the price you see is the price you pay. When the seats are gone the price goes back up.

10 seats left at this price0 of 50 claimed

10 seats at $16910 left
20 seats at $219−37%
20 seats at $259−26%

You save $180 at today's price. Every licence bought at launch is a full licence — same product, same updates, same support terms as it will have at $349.

You'll also need Bicrypto and Ecosystem for Bicrypto

On its own, Hummingbot Connector won't work — it only runs if you already own these products. Open the Requirements tab to see exactly what you need and add them to your order.

See it working Live demo Documentation View on CodeCanyon

A Binance-shaped REST surface, so Hummingbot's stock parsers need no changes
HMAC-signed requests with single-use nonces — a key string alone proves nothing
8 scopes in 5 presets, and none of them withdraw, so a leaked key cannot drain
IP allowlist and expiry per key, so a stolen secret is useless from anywhere else
One multiplexed WebSocket: books, trades, mark price, funding, orders and fills
Spot lands in the Ecosystem engine and perps in Futures — your book, your wallets
Six strategy presets, published, so nobody guesses a spread ladder on day one
A bot console that reads back your own rows — no bot hosting, no extra storage
Global kill switch and read-only mode, one for an emergency and one for upkeep
Per-account cancel-all and flatten, so one runaway bot is one click to stop
Server-run market makers started, stopped and diagnosed from the browser
Per-key rate-limit overrides, to throttle one bot without slowing everyone else

Inside Hummingbot Connector

Your platform becomes a venue a bot can trade on

An off-the-shelf market maker connects to your exchange with a signed API key and starts quoting — and every order it places is an ordinary row on your own book. It is a bridge, not an engine: spot flow goes to the Ecosystem matching engine and perpetual flow to Futures, so nothing about your custody, your ledger or your fees changes.

In detail

Your exchange becomes a venue an off-the-shelf market maker can trade on. A customer drops a connector package into their own Hummingbot, mints a signed API key on your site, and their bot starts quoting your pairs — and every order it places is an ordinary row on your own book, settling through your own wallets. You can run market makers of your own too, supervised from the admin panel, so a new listing does not launch with an empty book.

How it works

It is a bridge, not an engine: this addon owns no order book. Spot orders are forwarded to the Ecosystem matching engine and perpetual orders to the Futures engine, so fees, custody and settlement are unchanged. Bots talk to a Binance-shaped REST surface at /api/hb plus one multiplexed WebSocket, and every bot-facing call is signed — HMAC-SHA256 over the method, path, timestamp, single-use nonce and body. That signature is verified before expiry, disabled state, clock drift or IP, so knowing a public key string tells an attacker nothing.

The surface you configure

Surface	What ships	Yours to set
Key scopes	8 scopes in 5 presets	the bundle a key gets, IP lock, expiry
Rate limits	trade 600/60s, data 1200/60s, account 240/60s	per-bucket defaults, plus an override on one key
Strategy presets	6 published — 4 market making, 2 cross-exchange	spread ladder, sizes, refresh, risk barriers
Global controls	kill switch and read-only mode, both off	when to throw either one
Server-run bots	supervised instances, 1536 MB cap each	market, preset, key, memory ceiling, auto-restart

What operators control

Seventeen permission keys split five admin screens, so a support role can read the key registry without reaching the kill switch. The registry carries every Hummingbot-capable key with its scopes, expiry, disable reason and audit trail. The Command Center lists every account running a bot and gives you force cancel-all and flatten per account. Bot Instances registers a Hummingbot checkout on your own server, diagnoses it against nine checks, then starts, stops and streams its logs to the browser.

Two hard dependencies: Bicrypto core, and the Ecosystem addon — that is the book spot orders route to. Add Futures only if you want perpetuals; without it the perpetual paths return a clean 503 and everything spot keeps working. Redis is required for nonce replay protection. And Bot Instances is for your own market making, not hosting for users: one bot costs 400–700 MB, about 1.2 GB for cross-exchange making, on the same host as your database.

A credential that can trade and can never withdraw

Bots authenticate with an HMAC-SHA256 signature over the method, path, timestamp, single-use nonce and body — not a session token. Eight scopes ship in five presets, and not one of them moves money off the platform, so the worst a leaked secret can do is trade badly. Keys can be locked to an IP, given an expiry, disabled from either side and rotated; the signing secret is shown once and no administrator can read it afterwards.

The signature is checked before expiry, disabled state, clock and IP, so knowing a public key string tells an attacker nothing. Requests more than ten seconds from your server's clock are refused — a drifted clock on the bot's host is the most common failure this product has. Nonce replay protection needs Redis.

Every channel a market maker needs, on one socket

A single WebSocket carries eleven channels: seven public ones — the spot book, trades, ticker, the perpetual book, mark price and funding rate among them — and four private ones for a customer's own orders, balances, positions and fills. The public seven need no key. The private four need a signed handshake sent in-band on the same connection, checked by the same HMAC path the REST routes use, and until it arrives the subscription is refused outright: the topic comes back in the acknowledgement's rejected list instead of being accepted and then sitting silently empty. Once a socket signs it is bound to one verified account and no other connection can be handed its data. Fills arrive as their own events, derived server-side from the executed amount, carrying an id that dedupes against the same fill fetched over REST.

The server publishes on a timer rather than hooking into the matching engine: the book ticks every 200 ms by default, trades every 500, the ticker every second, and every interval is set per deployment. There is no diff channel — the depth channel sends the same full snapshot the book channel does. A refused topic is not queued behind the handshake either — the bot signs, then subscribes again. One connection takes 200 subscriptions and 20 client messages a second.

Stop one bot, or every bot, from the admin panel

A Command Center lists every account running a bot with its live orders and positions, and gives you force cancel-all and flatten per account. Two global switches sit above it: a kill switch that refuses every signed request, and a read-only mode that blocks placement and cancellation while market data and balances keep working. Each key also carries its own disable, rate-limit override and audit trail.

Disable the key first, then cancel — a market maker re-quotes within seconds of losing its orders. Both switches ship off and both fail open, so a settings or cache outage can never halt your exchange by accident.

Run your own market makers, without a terminal

Bot Instances registers a Hummingbot checkout on your own server and supervises it: start, stop, restart, reinstall the connector, diagnose it against nine environment checks and read its logs in the browser. Buttons record intent and one reconciler converges the process, so a double-click is harmless and a bot you asked to run comes back after a deploy. Six strategy presets — four pure market making, two cross-exchange — are seeded published so nobody guesses a spread ladder on day one.

This is for your own liquidity, not hosting for users. One bot costs roughly 400–700 MB, and about 1.2 GB for cross-exchange making, on the same host as your database. The memory watchdog is enforced on Linux only.

endpoints a bot can call: 23
scopes, none for withdrawal: 8
strategy presets, published: 6
admin permission keys: 17

Everything included

91 capabilities, in 8 areas

Every item below exists in the source you receive. Nothing here is a roadmap.

The connector your customers install

Hummingbot has no idea your exchange exists until this package is inside its own checkout.

A spot connector package for Hummingbot v2, named so `connect bicrypto` finds it
A separate perpetual connector package for derivative trading
A market-making controller module that ships with both
An installer that copies both packages, patches setup.py and proves the import
Installer modes: read-only audit, clean reinstall, and force over a broken copy
A local agent script that carries its own message broker and needs nothing installed
The whole kit downloaded as one zip, identical for everyone and carrying no credentials

Signed API keys

The credential a bot trades on, and every dial on it.

HMAC-SHA256 signature over the method, path, timestamp, nonce and body
Single-use nonces, replay-checked and held for twice the receive window
A ten-second receive window, the refusal naming the drift and its direction
Eight scopes, splitting account reads, market reads, spot, perpetual and bot control
Five scope presets on the key form: read-only, spot, perpetual, bot control, full
No scope that can withdraw or move funds off the platform
Per-key IP allowlist that denies by default when the list is empty
Optional expiry, set in days at creation
The signing secret shown once and excluded from every later response
Secret rotation that invalidates the old one immediately
Disable and re-enable, from the customer's side and from yours, stamped differently
A per-key audit trail: creation, rotation, scope changes and every rejection
A per-user key cap, and an optional verification requirement on create and rotate

The exchange a bot sees

A Binance-shaped REST surface, so an off-the-shelf bot's stock parsers need no changes.

Exchange info with price, lot-size and minimum-notional filters and real precision
Public liveness, server time, 24h ticker, order book snapshot and recent trades
A separate perpetual feed: contract info, order book and the current funding rate
LIMIT and MARKET orders on both desks, with your own client order id
Order list, single lookup, amend, cancel and batch cancel
Perpetual orders that can carry a stop-loss and a take-profit price
Per-symbol leverage, refused by naming the leverages the market actually offers
Open positions, and account balances across the funding and futures wallets
Real HTTP status codes and a machine-readable error envelope, so a bot can parse a refusal
Three rate-limit buckets — trade, market data, account — billed per key
Budget headers on every response, and a retry hint on every refusal

The live data feed

One socket, multiplexed, public and private on the same connection.

Eleven streams a bot subscribes to by name
Spot order book, public trades and ticker, each on its own channel
Perpetual order book, mark price and funding rate as their own channels
Private order, balance, position and trade streams behind an in-band signed handshake
Fill detection derived server-side, at a cadence you set without a restart
Both common keepalive conventions answered

Strategy presets

A preset is a row, not a file — the YAML is generated from it on demand.

Two controller families: pure market making, and cross-exchange market making
Six presets seeded and published on install, so the catalogue is never empty
Spread ladder, per-level allocation, refresh cadence and cooldown
Triple-barrier stop loss, take profit and time limit
Leverage per preset for perpetual market making
Cross-exchange hedge venue, per-level profitability targets and a re-quote band
Draft and published states, with the version bumped on every save
YAML preview and download, printing the exact two filenames to save it under
Validation on save and again on export, so a stored preset can never emit broken YAML
A published catalogue your customers download for their own bots

Your own market makers, on your server

Register an install by its checkout path and its own interpreter
A detection pass over a bounded set of host locations, each offered with a confidence
Provision a location: validate a path, create it, or clone the Hummingbot source into it
A nine-check diagnostic that tests the real server and reports pass, warn or fail
Start, stop and restart recorded as intent and converged by a single supervisor
Five instance states: stopped, starting, running, stopping, crashed
A graceful stop that gives the bot twenty seconds to pull its resting quotes
Auto-restart with backoff, reset by a stretch of healthy uptime
A memory ceiling per instance, so a runaway bot dies before your database does
A host memory panel showing committed, free and total, read from the real machine
A full-page bot terminal per instance: quote ladder, fill tape and the process log
Crash cards that name a probable cause and the next action, not an exit code
Re-adoption of a bot that outlived a backend restart, verified before it is adopted
Reinstall the connector into a checkout from the browser, refused while it is running
The Hummingbot config password encrypted at rest and handed over by environment
A market preflight against the real market list, at registration and again at start
Mint a scoped trading key for one instance from its own form, never returned to the browser
Linux subsystem and running virtual-machine guests listed on a Windows host, so you provision where it can build

Oversight and emergency control

The screens you open when something is going wrong.

A registry of every Hummingbot-capable key on the platform, with scopes and expiry
A posture band splitting enabled from disabled, click-to-filter
Fleet flags: expired but enabled, throttled, no secret, 24h failures, used in 24h
Disable any key with a reason that is returned verbatim to the bot
Bulk disable, with a confirmed count and per-key failures reported rather than rolled back
A per-key rate-limit override on any of the three buckets, and a way to clear it
A global kill switch that refuses every signed request
A read-only mode that blocks placement and cancellation while reads keep working
Both switches fail open, so a cache outage can never halt your exchange by accident
A Command Center listing every account currently running a bot
Drill into one account's live orders and open positions
Force cancel-all for one account, spot and perpetual together
Flatten: cancel the orders and close every open position
Seventeen permission keys, so a support role can read the registry without the kill switch

What a customer gets

A read-back of rows you were already storing — no bot hosting, no extra storage.

A live bot console showing resting quotes with age and distance from the touch
A fill tape deduplicated by order id and cumulative amount, so a replay cannot double-count
Inventory skew and open perpetual positions
The book spread and the customer's own quoted spread, side by side
A per-market rail when one account quotes more than one pair
Five-minute fill count, traded volume and notional still resting on the book
A health verdict with the remedy attached
Five link states, including the one that matters: authenticated once, silent since
An emergency stop that disables keys first and only then cancels
A setup page that computes the outstanding step from the account's real keys
A control tab and a bot log tab once the optional local agent is connected
Eight agent commands, enumerated server-side: status, start, stop, history, config, import and two balance controls

Licence: An extension licence activated in the platform's extension manager. Both the bot surface and the admin surface are licence-enforced, so an expired licence takes the whole product down at once rather than one screen.
Requires: Bicrypto core and the Ecosystem addon. Ecosystem is the book spot orders are matched on — this addon forwards to it.
Optional: Futures, and only for perpetual trading. Without it every perpetual path returns a clean 503 and the whole spot side keeps working.
Runs on: Your own server, beside the platform. There is no hosted tier.
Also needs: Redis — nonce replay protection, rate-limit counters, agent presence and command relay all live there.
On the bot's side: Hummingbot v2, built from source in a conda environment, on whichever machine runs the bot — your customer's or yours.
Processes: No new process. The market-data schedulers and the instance supervisor run inside the backend, and the supervisor starts on the main thread only.
Screens: 11 — six admin, five customer-facing
Access control: 17 permission keys across the five admin sections
Endpoints: 69 HTTP routes and four WebSockets: 23 a bot calls, 14 the browser calls, 32 admin
Settings: 12 keys — two global switches, a per-user key cap, two verification controls, six rate-limit budgets and the fill-detection cadence
What it stores: Two tables of its own: strategy presets, and the server-run instances. Keys are ordinary platform API-key rows carrying this addon's scopes, so disabling, rotating and auditing one behaves like every other key on the platform.
Integrates with: Hummingbot's own connector interface. A cross-exchange preset's hedge leg is your own account on an outside venue, connected inside Hummingbot and funded by you.
It owns no order book: This product signs, routes, meters and supervises. Every order is priced, matched and settled by Ecosystem or Futures, which is exactly why your fees, custody and ledger do not change — and why an install with no tradable market looks healthy right up until a bot connects.
LIMIT and MARKET only: Both desks accept LIMIT and MARKET. A perpetual order can carry a stop-loss and a take-profit price, but STOP and TAKE_PROFIT as order types are refused, and time-in-force is always good-till-cancelled.
Two strategy families: Pure market making and cross-exchange market making. Anything else is a controller you write and drop into the checkout yourself.
Server-run bots are not user hosting: Bot Instances supervises your own market makers, a handful of them. One process costs roughly 400–700 MB, and about 1.2 GB for cross-exchange making, on the same host as your database. One per customer is not what this is.
The memory ceiling only bites on Linux: Elsewhere the cap is recorded and never applied, and the panel says so rather than implying protection it does not have.
The bot control channel needs Linux or macOS: Hummingbot's own message bridge cannot attach to any broker on Windows. Orders, balances, market data, the REST surface and the console all work there — starting and stopping a bot from the browser does not.