Pagination and errors
Consume lists predictably and recover from REST API failures.
Pagination is endpoint-specific. Where a list supports cursors, request a bounded limit and pass the returned nextCursor back as after; the usual cursor response contains items, nextCursor, and hasMore. Do not assume every list is cursor-paginated. Inbox uses its own cursor form, Activity sessions use numbered pages, and several resource lists are intentionally unpaginated. Check the generated reference for the route you are calling.
Request-schema failures use the 400 VALIDATION_ERROR envelope. Scope failures use 403 INSUFFICIENT_SCOPE; unexpected handler or middleware failures use 500 INTERNAL_ERROR. Parse the shared { success, data, error } structure before treating a response as usable, and retain the error code in your logs so operators can distinguish malformed requests from authorization mistakes.
For retries, retry only failures that are safe for the operation. Reads and idempotent updates can often be retried after a transient error; creations, sends, and externally visible actions need an idempotency strategy in your own service. Never retry validation or scope errors unchanged: fix the input or key configuration first.