Pagination

How limit, offset, total, and has_more work across every list endpoint, plus the per-endpoint caps.

Every list endpoint returns the same pagination block in the response envelope:

{
  "data": [ /* … hits … */ ],
  "pagination": {
    "limit": 25,
    "offset": 0,
    "total": 1247,
    "has_more": true
  },
  "meta": { "request_id": "req_…", "dataset_status": "live" }
}

Parameters

Name	Type	Default	Max	Description
`limit`	integer	`25`	varies (see below)	Number of hits to return for this page.
`offset`	integer	`0`	—	Number of hits to skip before returning.

limit is clamped to the per-endpoint maximum. Sending limit=10000 doesn't error — it returns the cap. Check pagination.limit in the response if you want to confirm.

Per-endpoint caps

Endpoint	Default	Max
`GET /entities/search`	25	500
`GET /officers/search`	25	200
`GET /agents/search`	25	200
`GET /addresses/search`	25	200
`GET /filings/recent`	25	200
`GET /filings/daily`	50	500
`GET /leads/new-businesses`	50	500
`GET /sample`	5	25

The /sample endpoint is intentionally tight; the production endpoints scale higher.

`has_more`

has_more === true means at least one additional hit exists after the current page (i.e. offset + limit < total). The cheapest way to advance:

import requests

base = "https://api.floridabusinessapi.com/v1/entities/search"
headers = {"X-API-Key": "fbapi_live_..."}
offset, limit = 0, 100

while True:
    r = requests.get(base, headers=headers, params={"name": "realty", "limit": limit, "offset": offset}).json()
    for hit in r["data"]:
        process(hit)
    if not r["pagination"]["has_more"]:
        break
    offset += limit

`total`

total is the exact match count for the query (not just the current page). It is computed with COUNT(*) OVER () in the same SQL pass — no extra round-trip, no rate-limit cost.

If your client doesn't need an exact count, you can ignore the field. We do not currently support a noCount=true shortcut.

Errors

Status	Code	Cause
`400`	`bad_request`	Negative `offset`, non-integer values.

See Errors for the full envelope shape.

Stable ordering

Pagination is only stable if the SQL ordering is deterministic. Every list endpoint applies a secondary tiebreaker — for /entities/search that's filing_date DESC, document_number ASC. If you rely on cursor-style stability across hours/days of inserts, prefer date-range filters (filing_date >= "YYYY-MM-DD") over deep pagination — the dataset grows daily.