Access
What a project needs before it can call this API, and the one thing you still have to ask us for.
Three separate things decide whether a call succeeds: whether the project can hold a key, whether the key authenticates from where you are calling, and - for money only - whether the project is open for spending. They are separate on purpose, so no single mistake and no single stolen credential is enough on its own.
Keys are self-serve
Generate a keypair, upload the public half under your project's API keys, and you have a key id. There is no application, no enablement request and nothing to wait for, in either sandbox or live.
This changed on 2026-09-18. Both surfaces used to be granted per project by us, which made "can I try it" a conversation rather than a signup. If you read older notes saying you need us to switch API keys or sandbox on for you, they are out of date.
We never hold your private key
Which means we cannot reissue it. Rotation is register-a-second-key, then revoke the first. See Signing.
The IP allowlist is not optional
A key authenticates only from the addresses listed against it. There is no permissive default and no wildcard - a key with an empty allowlist is a key that cannot be used.
This is the part integrators most often meet first, because it fails on call number one.
ip_not_allowed means exactly what it says: the signature was fine, the address was not
listed. Egress addresses are easy to get wrong when your code runs behind a NAT or on a
platform that rotates outbound IPs, so list every address your traffic can leave from.
Moving money still needs enabling
Every read-and-receive endpoint works the moment you hold a key. The endpoints under Money do not: they need two independent grants.
- The key must carry the
moneycapability, chosen when you register it. A key without it cannot spend, whoever holds it. - The project must be opened for money over the API, which is ours to switch on - talk to us.
Either one alone does nothing. A leaked key cannot pay anybody unless the project was also opened, and an opened project arms no key that was not separately granted.
Until both are in place, those endpoints answer 403 with details.code of
capability_required (the key) or api_money_not_enabled (the project). Two codes
rather than one because the fixes are different: the first is a key you register again,
the second is a conversation.
Why this one stayed gated
Holding a credential and spending from a balance are different risks, and only the second is irreversible. Opening keys to everyone was worth doing precisely because a key on its own cannot move value - that property is what makes it safe, so it is not one we hand away in the same motion.
Either surface can be closed again
A project can be restricted, and both surfaces can be closed platform-wide, without touching your key. The check runs on every request rather than at registration, so access that is withdrawn stops working on the next call - and access that comes back needs no new key.
Two codes, because the fixes differ:
details.code | What happened |
|---|---|
api_access_revoked | This project is no longer open for API access at all. |
sandbox_unavailable | The key is a sandbox key and sandbox is closed for this project. A live key on the same project is unaffected. |
Treat them the way you would treat any other refusal on this API: switch on
details.code, and default an unknown code to failure. See Errors.