Skip to main content
Every request to the ZLL Trading API carries a credential, and which one depends on what the request does.
Rule of thumb. Read state with a header credential. Move money or change keys with a signature.
Reads carry an opaque key in a header. Writes carry a signature over the request bytes. Pick the credential that matches the operation, present it the documented way, and the exchange checks the credential’s scope.

​
Read vs. mutate

Read state

Account, orders, fills, positions, funding, sessions. Present an API key (X-API-KEY) or device key (X-DEVICE-KEY) in a header. No signing.
See Read credentials.

Move money or change keys

Order entry, transfers, withdrawals, session and master-key management. Sign the request bytes and send a signed payload. No header key authorizes a write.

​
Credential map

Five long-lived credentials and two one-shot tokens. Each request type maps to exactly one.
CredentialWhat it isUsed for
Master keySecp256k1 (EIP-712) or Passkey (WebAuthn). The account root.Mint and revoke sessions; manage other keys.
Session keyEd25519, minted by a master key.Sign trading, cash, and key-management writes.
API keyOpaque string in X-API-KEY.Read-only programmatic access.
Device keyOpaque string in X-DEVICE-KEY.Reads, plus minting pairings and WebSocket tickets.
Device-pairing tokenOne-shot bearer token.A single write to one pairing mailbox.
WebSocket ticketOne-shot ticket.One private WebSocket connection.
Every minted secret is returned once, in the body of the call that mints it. The exchange keeps no recoverable copy. Store it immediately; if you lose it, mint a replacement and revoke the old one.

​
How writes are signed

A write packs [Header || RequestId || Body], signs those bytes with the credential’s private key, and sends a Base64SignedPayload envelope. The curve depends on the credential. The signed payload page covers the byte layout and per-curve signing (Ed25519, Secp256k1, Passkey); session signatures cover the X-PUBLIC-KEY / X-SIGNATURE / X-REQUEST-ID header triple for session-signed reads. Accepted signed writes return a RequestAck — { status, processed_at_ns }. A 200 OK is not proof of acceptance; always read the body before treating a write as done. See Error model.

​
You build the signing yourself

Official SDKs are coming soon and will handle signing for you. For now, the exchange publishes the wire contract — envelope, byte layout, curves, headers — and you implement signing in your own client. Start with the signed payload page, then check Common signing mistakes before you go live.

​
Withdrawals are admin-rooted

A withdrawal is signed by a session key at the wire level, but the exchange rejects any session that is not admin-rooted — an unpinned session minted under an admin master key. A valid signature alone is not sufficient. A pinned session, or a session rooted on a scoped key, is rejected even though the signature verifies.
The same rule governs subaccount creation and admin-scope key management. See Withdrawals security.