Permissions, background jobs and Redis keys

Three things decide whether this integration works for somebody other than you: which permission keys their role holds, whether the cron process is running, and whether a Redis key is quietly telling every spot path to do nothing. All three are listed here.

The connection itself — clock sync, instance caching, rate limits, the proxy — is in Connection, rate limits and bans.

Permissions

Two different layers read these keys and they read them for different reasons.

• access.* keys decide what an operator can see. frontend/config/menu.ts hides a menu entry whose permission the role does not hold, and the admin data tables refuse to render without their access key. No backend route is gated on an access.* key.
• view.* / create.* / edit.* / delete.* / manage.* keys are what the API enforces. A missing one answers 403 Forbidden - You do not have permission to access this.

Super Admin bypasses every check. The role gate short-circuits on userRole.name === "Super Admin", so a permission problem is invisible while you are testing as the owner account. Test role changes on a real staff account.

The exchange surface

The money surface

Withdrawals, wallets and the transaction ledger are core screens, not exchange-provider screens, so their keys are unrelated to exchange.*. An operator who is meant to handle customer payouts needs these as well.

Keys that are seeded but gate nothing

The permission seeder writes these; no route or screen in the Binance surface checks them. Granting them changes nothing, and their absence is not your bug.

The one grant to think twice about

edit.exchange is not "can edit some settings". It is two very consequential powers behind one key:

• It can switch the whole spot back end to another exchange. PUT /api/admin/finance/exchange/provider/{id}/status disables every other provider in the same transaction. So does the licence activation route. The markets, currencies, open orders and customer balances all stay pointing at Binance — see Switching the active exchange provider for what that costs.
• It can route every exchange call through a host of the holder's choosing. The proxy field on the exchange hub's Settings tab is saved by PUT /api/admin/finance/exchange/provider/{productId}, which also evicts the cached connection so the next request rebuilds through the proxy. Credentials embedded in the URL are masked on read (//***:***@), so the value cannot be read back out of the panel — but everything the platform sends to Binance, signed with your API key, goes through whatever was saved.

view.exchange is safe to hand out. edit.exchange belongs to the same small group of people who hold the .env file.

Background jobs

All of these run in the cron process, not the web process. production.config.js starts backend with CRON_MODE=off and a separate cron app with CRON_MODE=only; a single-process install sets CRON_MODE=inline instead. If the cron app is not running, none of the reconciliation below happens and nothing on any screen says so.

Two of these are load-bearing in ways their names do not suggest.

reconcileSpotWithdrawals is the one that prevents a customer being left short. It only looks at PROCESSING + WITHDRAW rows older than 5 minutes, scoped away from Ecosystem rows, and it caps itself: 200 rows per run, at most 2,000 rows scanned while paging past ones already in review backoff. A large backlog therefore clears over several runs rather than one. Rows older than 24 hours become eligible for an evidence-based refund after a 1,000-record lookback against Binance's own withdrawal history.

processPendingWithdrawals skips a row with no referenceId. That is deliberate — a row with no exchange id has not been sent, so this job has nothing to look up. Those rows are reconcileSpotWithdrawals's job.

cacheExchangeCurrencies, and the cache that is usually cold

The job writes the enabled-currency list to Redis under exchangeCurrencies with a 120-second TTL, tied to the 120-second price cadence so the cached price can never be more than one tick behind the row.

The job itself runs hourly. The arithmetic is unavoidable: the key exists for two minutes out of every sixty, and for the rest of the hour /api/exchange/currency and /api/exchange/currency/{id} miss and read the database instead. The endpoints never repopulate the key — they fall back and return, they do not write. So the cache is a small hourly optimisation, not a dependency, and a Redis outage does not take the currency endpoints down.

What it does mean: nothing else warms this key. If you flush Redis, the currency endpoints are on the database until the next hourly tick, which is fine, and if you were expecting the cache to absorb load it is not doing that.

Watching them

Admin → System → Cron (/admin/system/cron) lists every job with its last run, last error and next scheduled run, and streams live progress over a WebSocket.

A job that throws is recorded with lastRunError and a failed status; processPendingSpotOrders deliberately rethrows so a dead reconciler is distinguishable from a healthy one on that screen.

Backend log tags worth grepping: EXCHANGE (connection, credentials, clock, ban), SPOT_RECON (order reconciliation), WITHDRAW and WALLET (payouts), SPOT_DEPOSIT (the live deposit verifier), CRON (the jobs themselves).

Redis keys

Note what has no TTL. An ohlcv:* key written by Build charts or Fix gaps self-expires after 24 hours, so the keys an operator creates from that screen do clear themselves. The same key written by the public chart read-through path does not, and the gzipped files behind it never expire at all — so a miss just reloads the old candles from disk into Redis with no TTL, which is why candles from a previous provider keep being served after a switch. Clean on /admin/finance/exchange/chart is what removes both. exchange:tickers is a single key rewritten in place.

exchange:ban_status is a kill switch

The value is an epoch-millisecond unblock time, stored as a string, with the key's TTL set to the remaining seconds so it clears itself.

It is written in two places:

• The rate-limit handler. A ccxt.RateLimitExceeded, or Binance code -1003, while the connection is being built records a one-minute ban and sleeps a minute before retrying.
• Any error message containing IP banned until <epoch>. That number is scraped out of the free-form text and used as the expiry.

Both go through the same clamp: a time already in the past, or one that does not parse, is ignored; a time more than 24 hours away is clamped to 24 hours with a warning naming the original value. That guard exists because the number comes from error text — a units mismatch would otherwise park a permanent outage in a key nothing routinely inspects.

What we could not determine

• There is no admin screen that lists Redis keys or lets you delete one. Clearing exchange:ban_status means a redis-cli DEL on the server.
• Nothing records which permission key a 403 was raised for, on the client side. The response is the generic "Forbidden - You do not have permission to access this"; identifying the missing key means reading the route's metadata or the backend log.

Related

• Connection, rate limits and bans — how the ban gets set in the first place, and what the connection caches
• The spot desk — the screens these permissions open
• Float, treasury and reconciling — what the reconciliation jobs cannot do for you