starting_after and ending_before.
Endpoint shape
- Base URL: https://api.bridge.xyz
- Typical list endpoint pattern: GET /v0/
- Default order: newest → oldest (unless an endpoint specifies otherwise)
- Page size: controlled by
limit(maximum 100) - Pagination: cursor-based using item
idvalues
Api-Key header.
Security note: do not hardcode live keys in source or docs; use environment variables.
Query parameters
limit- Description: number of items to return
- Range: 1–100
- Tip: set explicitly (e.g.,
limit=50) for predictable pagination
starting_after- Description: fetches items that come after the given id in the default ordering, i.e., older items
- How to use: pass the last item’s id from your current page to get the next page of older results
ending_before- Description: fetches items that come before the given id in the default ordering, i.e., newer items
- How to use: pass the first item’s id from a known page to retrieve any items that are newer than it
starting_after or ending_before per request.
Response shape
- data: array of resource objects (0 to
limititems) - count: number of items in this page (if provided by the endpoint)
- Stop condition: when
datais empty, there are no more items in that direction
data vary by resource. All paginable resources include an id used as the cursor.
cURL examples
Use an environment variable for your API key:- macOS/Linux: export BRIDGE_API_KEY=“sk_live_…”
- Windows PowerShell: $env:BRIDGE_API_KEY = “sk_live_…”
1) Fetch the first page (newest first)
This returns the newest 3 items:- First item’s id: newest on this page
- Last item’s id: oldest on this page
2) Get the next page of older items
Usestarting_after with the last id from the previous page:
3) Fetch newer items since a known id
If your last run’s first item id was , useending_before to get any newer items:
Practical patterns
Backfill all historical items (older direction)
- Request with your chosen
limit(e.g., 100). - Process the page.
- Save the last id from the page (the oldest in this batch).
- Repeat with
starting_after=<last_id>untildatais empty.
Periodically check for new items (newer direction)
- Save the first id from your last successful fetch (the newest you’ve seen).
- Request with
ending_before=<that_first_id>. - If
datais non-empty, process the new items and update your saved first id to the newest id returned. - If empty, nothing new is available.
Boundary behavior
- Reached oldest items: using
starting_aftereventually returnsdata: []. - No newer items: using
ending_beforemay returndata: [].
Tips and best practices
- Treat item ids as stable cursors; always use the first and last ids from each page for the next request.
- Don’t combine
starting_afterandending_beforein the same call. - Stick to a consistent
limitfor predictable throughput; max is 100. - Expect partial pages near the ends (fewer than
limititems). - If you need to process items oldest-to-newest, reverse the page locally after fetching.
- When running concurrent pagination and ingestion, de-duplicate by
idin your datastore.
Minimal JavaScript examples
Assume a helper fetchFn(path) that does authenticated fetches relative to https://api.bridge.xyz.Backfill older pages
Poll for newer items since a known id
Summary
- Results are newest → oldest by default.
- Use
starting_after=<last_id>to go older. - Use
ending_before=<first_id>to fetch items newer than a known id. - Control page size with
limit(max 100). - Stop when
datais empty in the direction you’re traversing.
