One base URL
Everything about the chain lives under /api/v1/ on this gateway, same origin as
this page — no CORS to negotiate, no key to obtain, no rate plan.
curl https://this-gateway/api/v1/blockchain/statusReads and writes go to different places, which matters more than it sounds:
| GET | proxied to an archival node, which holds the deep history — blocks, transactions, accounts as of any height. |
|---|---|
| POST | proxied straight to a full node, never to archival. Submitting a transaction needs a mempool, and an archival node is a read-only history service — it used to answer POST with 404, which is why broadcasting through a gateway once did not work. |
The routes you will reach for first
| /api/v1/blockchain/status | height, confirmed height, latest block |
| /api/v1/blocks/latest | the newest block in full |
| /api/v1/accounts/<address> | balance and spendable balance. Takes a
ZBC_… address or the raw 36-byte hex |
| /api/v1/accounts/<address>/tokens | every token that account holds |
| /api/v1/transactions?limit=25 | recent signed transactions |
| /api/v1/movements/latest | balance changes the chain makes itself — rewards, vesting, refunds |
| /api/v1/exchange/markets | open markets; …/orderbook?market=<id>
for depth, …/offers for swap packages |
| /api/v1/tokens | every token, with supply and decimals |
| /api/v1/release/list | published releases and their hashes — what /verify checks against |
| /api/v1/registry/nodes | the node registry; also
/gateways, /relays, /archivals |
Some routes exist only on an archival node and some only on a full node. This gateway tries archival first and retries the node API on an empty-bodied 404, so you rarely have to care which is which — but a 404 with a body is a real answer, not a wrong turn.
Submitting a transaction
Build and sign it with zbc-cli, which takes its parameters as JSON on stdin so a
private key never lands in ps or your shell history:
echo '{"sender_privkey":"…","recipient":"ZBC_…","amount":100000000}' \
| zbc-cli send --json-input --api https://this-gateway1 ZBC is 108 atomic units. Every amount in the API is atomic — there are no decimals anywhere in the wire format.
Full reference
Every route, its parameters and its response shape:
Open the API reference → · alternate view
Both addresses serve the same document.
Downloads
Files an operator has published on this gateway are served at
/dl/<name>. Names are a single segment of [A-Za-z0-9._-], and
everything is sent as an attachment and never rendered — this origin also serves the wallet, and
a page rendered here would inherit the wallet's origin.
Release bundles live under /releases/<version>/<arch>/, with
/releases/latest naming the current one. The node installer is at
/install.
Is this gateway healthy? checking…
/gateway/status reports what this gateway knows about itself and the nodes it
can reach — mode, domain, how many nodes are on its allowlist, which are answering.
/gateway/system-stats reports the machine: CPU, memory, disk, uptime. It is what
the figures on the gateway page are drawn from.
curl https://this-gateway/gateway/status
curl https://this-gateway/gateway/system-statsNeither needs a key. Neither exposes anything about the chain — for that use
/api/v1/… above.
Reaching one specific node
The chain routes answer from whichever archival node this gateway picks. To query a
named node, put its IP in the hostname — dots become dashes, and an optional
-p<port> chooses the API port:
curl https://ip-192-168-1-100.this-gateway/api/v1/node/info
curl https://ip-192-168-1-100-p8080.this-gateway/api/v1/node/infoOnly nodes on this gateway's allowlist answer. Anything else is refused rather than proxied, so the hostname cannot be used to reach arbitrary hosts through the gateway.
Relay
Voice, video and screen-share go peer-to-peer; when a firewall blocks a direct link a relay
carries the traffic for credit. /relay/info reports its address, its rate and the
genesis hash of the chain it settles on — a wallet compares that against its own node before
paying, because a relay on another chain cannot credit what it is paid.
curl https://this-gateway/relay/infoAdmin panel
The gateway's own controls live at /admin. It is protected by the
admin_api_key from /etc/zoobc/gateway.json, which the installer
generates per box — there is no default key.
The allowlist
A gateway only proxies to nodes it has been told about. That list is what stops the
ip-… hostname form from turning the gateway into an open proxy.
| POST /gateway/allowlist/add | admit a node — {"ip":"…","port":8080} |
| POST /gateway/allowlist/remove | drop one |
| POST /gateway/allowlist/refresh | re-read the registry and re-check health |
| GET /gateway/allowlist | what is currently admitted |
All three writes need the admin key. In public mode the gateway also discovers
nodes from the chain's own registry; in private mode it uses only static_nodes.
Release tooling
The offline signer signs a release bundle without the signing key ever touching a server — it is a self-contained page, meant to be opened on a machine that holds the key and nothing else. The file hasher computes a SHA-256 in the browser for anything you want to check by hand.