Pagination

LeadX uses page-number and cursor pagination across its public API. Follow the contract for the operation you call instead of assuming every endpoint uses page and per_page.

Page-number pagination

Send page and per_page in the JSON request body for these operations:

These responses include records, page_number, per_page, total_pages, and total_records.

curl --fail-with-body "https://api.leadx.com/v1/ucc/debtor" \
  -H "X-API-KEY: $LEADX_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "url": "example.com",
    "page": 1,
    "per_page": 50
  }'

{
  "success": true,
  "records": [],
  "page_number": 1,
  "per_page": 50,
  "total_pages": 0,
  "total_records": 0
}

An empty page is successful. When no records match, records is empty and both total_pages and total_records are 0.

Cursor pagination

Bulk email results use cursor pagination:

• GET /v1/emails/find/bulk/jobs/{job_id}/results

Start with cursor=-1. limit defaults to 100 and accepts 1 through 1,000. Pass next_cursor into the next request and stop when has_more is false.

?cursor=-1&limit=100
?cursor=99&limit=100

Merge bulk rows by external_id. Do not use array position as a durable source identifier.

Build a stable integration

• Reject values outside the operation's documented range before sending a request.
• Stop when the response indicates there are no more results.
• Do not infer a stable cross-request sort order unless the endpoint documents one.
• Store record identifiers and external_id values instead of relying on row position.
• Expect 422 Unprocessable Entity when a pagination parameter fails validation.