Pagination

Efficiently navigate large volumes of data using offset cursors.

Why do we paginate?

Endpoints that return collections of objects, like listing all your clients or quotes, can return hundreds of thousands of records. To ensure the Cord API is always fast and stable, these endpoints limit the number of objects returned by default (usually 50 or 100) using a pagination model based on limit and offset.

Query Parameters

All list reading routes (GET /api/v1/cotizaciones, GET /api/v1/clientes, GET /api/v1/productos) accept the following parameters in the URL:

• limit: (Integer) Determines the maximum number of results to return.
• offset: (Integer) Specifies how many results to skip before starting to return data.

Request Example (Page 2):

curl -X GET "https://cordhq.app/api/v1/clientes?limit=50&offset=50" \
     -H "Authorization: Bearer sk_live_tU..."

Response Structure (Meta)

All Cord paginated responses return a JSON object with two main properties: data (the array of objects) and meta (pagination information for your frontend or scripts).

{
  "data": [
    { "id": "cus_123", "empresa": "ACME Corp" },
    { "id": "cus_124", "empresa": "Stark Ind" }
  ],
  "meta": {
    "limit": 50,
    "offset": 50,
    "total": 142
  }
}

• Use meta.total to build pagination controls in your UI or to know exactly when to stop a data export script.

Exceptions: invoices and events use a cursor, not offset

Invoices are listed with keyset pagination (cursor / next_cursor), not limit/offset. With offset, a new invoice shifts the entire next page and can hide a record without you noticing — unacceptable in a listing that feeds collections or accounting reconciliation.

curl -X GET "https://cordhq.app/api/v1/facturas?limit=50" \
     -H "Authorization: Bearer sk_live_tU..."

{
  "data": [ { "id": "fac_...", "numero": "F-2026-104", "estado": "open" } ],
  "meta": { "next_cursor": "2026-08-20T14:32:00.000Z" }
}

next_cursor is the creation date (ISO 8601) of the last row on the page, not an opaque token: repeat the request adding ?cursor=<next_cursor> to fetch the next one. When there are no more pages, next_cursor comes back null.

GET /api/v1/events also paginates with a cursor, but its next_cursor is an opaque token: do not parse or build it, just send it back as-is in ?cursor=. See Event history through the API.