Home / API / Errors and limits

Errors and limits

Four status codes carry almost all the failures, and telling them apart saves real debugging time — particularly 400 versus 403, which fail for opposite reasons.

Status codes

CodeMeansWhat to do
400Invalid input — the value never reached a gate. Malformed token, malformed file ID, batch too large, unknown folder valueFix the shape of what you sent. Your credential may be perfectly valid
403Gate failure — well-formed input, wrong capabilityFix the credential. The request shape was fine
413Too large — payload over 5 MB, or an inline-content listing over the 3 MB ceilingSplit the payload, or list without inline content and fetch on demand
507Lane full — 1000 pending files for that tokenFetch and mark-processed, then purge the processed folder
The 400 that looks like a 403. Path and token components are validated by typed primitives before they reach storage, which is how path traversal is blocked at the type level. A prefixed token such as tok_abc… — or a CLI fingerprint pasted straight in, sha256:a461… — fails the hex-only pattern and returns 400. It reads like a rejected credential; it is a rejected string. Use raw hex.

Input patterns

InputPattern
append_token^[0-9a-f]{16,128}$ — hex only, no prefix
file_id (append)^\d{13}_[0-9a-f]{24}\.enc$ — server-assigned, so you should be echoing one back
vault_idlowercase alphanumeric, 8–24 characters, no hyphens

Limits

LimitValueOn breach
Payload per append write5 MB413
Pending files per append token1000507
File IDs per batch (fetch / mark / purge)100400
Operations per /vault/batch request100400
Inline content when listing3 MB cumulative413
Append list page size50 default, 200 maxclamped silently
read-base64 response~3.75 MBuse presigned reads above this

The page-size clamp is silent: ask for 500 and you get 200 with no warning. Page with after_file_id rather than assuming your requested size was honoured.