Skip to main content
The Bridge Hub API exposes interactive OpenAPI documentation at the /docs endpoint. You can browse endpoints and test API calls directly in the browser.
The Bridge Hub API is a read-only REST API. All endpoints use the GET method, and all responses are returned as application/json.

GET /transactions

Query bridge transactions with filtering and cursor-based pagination.

Parameters

Example request

Example response

Response fields

GET /claim-proof

Generate a merkle proof for claiming a bridge transaction. This endpoint proxies to the source chain’s AggKit Bridge Service to retrieve the proof data needed to submit a claim on the destination chain.

Parameters

Example request

Example response

Response fields

GET /token-mappings

Get token address mappings between networks. Returns the relationship between original token addresses and their wrapped counterparts on destination networks.

Example request

Example response

GET /token-metadata

Get token metadata including name, symbol, and decimals for tokens tracked by Bridge Hub.

Example request

Example response

GET /health-check

Returns the service health status.

Example request

Example response

Pagination

The Bridge Hub API uses cursor-based pagination for the /transactions endpoint.
  1. Make an initial request with an optional limit parameter.
  2. If more results exist, the response includes a nextStartAfterCursor value.
  3. Pass that value as the startAfter parameter in your next request to retrieve the following page.
Cursor-based pagination provides several benefits over offset-based approaches:
  • Stable results. Concurrent inserts or updates do not cause skipped or duplicated entries between pages.
  • Consistent performance. Fetching page 1,000 is as fast as fetching page 1, since the database seeks directly to the cursor position.
  • No deep pagination issues. There is no growing cost as you move further through the result set.

Error handling

The API uses standard HTTP status codes and returns structured error responses.

Status codes

Error response format

All error responses follow a consistent structure:
Error messages describe the problem without exposing sensitive internal details. If you receive a 500 response, retry the request after a short delay. For persistent errors, check the /health-check endpoint to verify service availability.