Authentication
Every request carries one header:
Authorization: Bearer east_live_...There are no key scopes: a key can do everything the account can. The key is shown once, at mint, and only its SHA-256 is stored, so a lost key is re-minted rather than recovered.
The two prefixes
Section titled “The two prefixes”| prefix | what it is |
|---|---|
east_live_ |
A live key. Extractions bill, quota applies, rate limits apply. |
east_test_ |
The sandbox sibling minted beside every live key. Walks every route, spends nothing. |
The two live in one namespace on purpose: same header, same routes, same response shapes, and one prefix character telling you which world you are in. Anything else would be a second code path, and a second code path is where “it worked in test” comes from. What the sandbox returns is covered in the overview.
A test key skips quota and both rate limits. It spends nothing, so there is nothing to protect, and an integrator hammering the sandbox while they get their retry logic right is precisely who the mode is for.
How many keys
Section titled “How many keys”Quota pools at the account, so a second key is never a second allowance. What it buys is separation: a key for the QGIS plugin and a key for a nightly script, and revoking the script’s key on a Friday without anyone’s plugin going dark on Monday.
A paid account holds up to ten live keys. A free account holds exactly one, because the rate ceilings below are per key: more keys would multiply what a free account can put in flight, which is the whole control those ceilings exist to provide. Buying anything lifts the account to the ordinary limit.
Keys are minted, rotated, and revoked with a signed-in session at app.easting.ai, never with another key. Managing credentials with one of the credentials being managed is a shape worth refusing: a leaked key would otherwise mint its own successors and outlive the revocation.
Rotation
Section titled “Rotation”Rotating a key mints a successor with the same name, caps, and owner, and
revokes the old one in the same transaction. The old key stops working
immediately: its next request answers 401 with type revoked_api_key.
Minting a second key is different from rotating. A minted sibling changes nothing about the keys you already hold; the old one keeps working until you revoke it.
Rate limits
Section titled “Rate limits”Two limits, because they catch different mistakes: a burst (a retry loop hammering submit) and a fan-out (a script firing five hundred documents at once, each already a model call in progress).
| limit | live key | free account |
|---|---|---|
| requests | 120/minute | 10/minute |
| extractions in flight | 25 | 2 |
These are protection for our model spend, not product tiering, and they are deliberately generous: anyone who reaches them is either looping by accident or wants a conversation, and both beat a surprise invoice. Email sales@easting.ai to raise them.
The limits admit the two single-document paths, POST /v1/extract and
POST /v1/extracts. Batch submission has neither limit, which is why the
in-flight refusal points volume at /v1/batches.
Batch items still count in the in-flight number, since each is a model call
already running.
Both limits answer 429 with a Retry-After header. Read it and back off; a
polling loop should wait between polls rather than spin.
401, 403, 429
Section titled “401, 403, 429”| status | what it means |
|---|---|
| 401 | The key is missing, malformed, unknown, or revoked. Fix the credential; retrying will not help. |
| 403 | The key is valid but the thing named is not yours. Only upload ids answer this way; other resources answer 404 so an id can never confirm it exists. |
| 429 | The key is valid and over a rate ceiling. Read Retry-After, wait, retry. |
Every one of these carries the standard error body; the types are in the error reference.