page and per_page parameters and we return the requested slice plus metadata about the total result set.
Endpoints that support pagination
GET /v1/dealers returns all dealerships under your account in a single response — it does not support pagination.Request shape
Response shape
Paginated responses always include this metadata:
The actual items live under a key named after the resource (
vehicles, deliveries, etc).
Walking all pages
Best practices
1
Use larger per_page values
Bigger pages = fewer round trips. The default of 50 is conservative; if you’re walking all pages, use a larger value like 200.
2
Don't store page numbers long-term
Page numbers are not stable across mutations. If new vehicles are added between page 1 and page 5, page 5 in your second walk may contain different items than the first. For reliable bulk syncs, use webhooks instead.
3
Cache page count, not pages
total_pages is fine to display in a UI, but don’t cache the actual page contents — they go stale fast.4
Combine with filters
Pagination is for navigating result sets. Filters (e.g.
condition) reduce the result set. Filter first, paginate second.When to use webhooks instead
Walking pages to “sync” inventory is fragile and inefficient. For ongoing inventory sync:- Do one full walk when you first onboard the dealership
- From then on, subscribe to
vehicle.created,vehicle.updated,vehicle.removedwebhooks - Apply each event to your local database
Edge cases
Cursor pagination
Some high-volume endpoints will move to cursor-based pagination in the future, which is more reliable for large or actively-changing result sets. When that happens, the existingpage/per_page will continue to work for backwards compatibility.
Related
Webhooks
Real-time alternative to polling
Inventory fetch endpoint
Full reference for the inventory fetch endpoint