Skip to main content
All list endpoints in the Just Flow It API (such as 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

integer
default:"20"
How many items to return per page. Must be between 1 and 100. Defaults to 20.
string
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:
array
The array of resource objects for this page. Each item carries its own object discriminator (for example "diagram" or "folder").
boolean
true if there are more items beyond this page, false if this is the last page.
string | null
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 while has_more is true, passing the previous next_cursor as the next cursor.
1

Request the first page

Call the list endpoint with your desired limit and no cursor.
2

Process the data

Handle the items in data.
3

Check has_more

If has_more is false, you’ve reached the end. Otherwise continue.
4

Follow next_cursor

Request the next page with cursor set to the previous response’s next_cursor, and repeat from step 2.
Use the largest limit (100) when bulk-syncing to minimize the number of round trips. Keep your loop driven by has_more rather than by an empty data array.

Invalid or expired cursors

Cursors are opaque tokens — never construct, modify, or persist them across long periods. If you pass a malformed or expired cursor, the API responds with 400 and an invalid_cursor error.
Always start a fresh traversal from the first page (no cursor) rather than reusing a stale next_cursor from an earlier run.
400 Bad Request
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.