How the APIs behave
Errors, pagination, retries and rate limits, the same across the management API and the account API.
Errors
Every error is a problem document (RFC 9457, application/problem+json) with a stable code, which never changes or gets reused once it ships: branch on it, never on the title or detail. Its type is the address of the code's page in the errors. insufficient_permissions names the permission the credential lacks in missing_permission, and validation_failed lists what was wrong with each field in errors.
Pagination
Every list takes ?limit= (1 to 200, 50 by default) and ?cursor=, and answers { data, next_cursor }. Pass next_cursor back as cursor for the next page, until it's null. A cursor is opaque: never build or read one. A row made while you page never moves the pages you haven't read.
Retrying a POST
Send an Idempotency-Key header with a POST to the management API, or a POST or PATCH to the account API, and a retry with the same key and the same request gets the first answer back (with Idempotent-Replayed: true) without anything happening twice. Answers are kept for 24 hours; one carrying a secret is kept only as having succeeded. The same key with another request is idempotency_key_conflict, and a retry while the first still runs is idempotency_key_in_flight. An error isn't kept, so a failed request can be retried as it is.
Rate limits
Requests are limited per address before authentication, and per API key or person after. Over a limit is 429 rate_limited with a Retry-After header: wait that many seconds. The issuers limit their endpoints and sign-in pages the same way, answering OAuth errors as JSON and browsers with a page in the brand's look.