GET /v1/diagrams and GET /v1/folders) use cursor-based pagination. Instead of page numbers, you fetch results in batches and follow an opaque next_cursor to walk forward through the collection.
Results are always ordered newest first (
created_at descending).Query parameters
How many items to return per page. Must be between 1 and 100. Defaults to
20.An opaque pagination token. Omit it on the first request. To fetch the next page, pass the
next_cursor value returned by the previous response.The list envelope
Every paginated response wraps the results in a consistent envelope:The array of resource objects for this page. Each item carries its own
object discriminator (for example "diagram" or "folder").true if there are more items beyond this page, false if this is the last page.The cursor to pass as
cursor on your next request to retrieve the following page. It is null when has_more is false.Example response
Fetching a single page
Looping through every page
To retrieve a full collection, keep requesting whilehas_more is true, passing the previous next_cursor as the next cursor.
Invalid or expired cursors
Cursors are opaque tokens — never construct, modify, or persist them across long periods. If you pass a malformed or expiredcursor, the API responds with 400 and an invalid_cursor error.
400 Bad Request
Why cursor-based instead of page numbers?
Why cursor-based instead of page numbers?
Cursor pagination stays correct even when items are created or deleted between requests, since each cursor encodes a stable position in the
created_at desc ordering. Offset/page-number pagination can skip or duplicate items when the underlying collection changes mid-traversal.