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

ParameterTypeRequiredDescription
statusstringNoFilter by status: BRIDGED, READY_TO_CLAIM, CLAIMED
sourceNetworkIdsstringNoComma-separated source network IDs
destinationNetworkIdsstringNoComma-separated destination network IDs
fromAddressstringNoFilter by sender address
receiverAddressstringNoFilter by receiver address
limitintegerNoResults per page (default: 50)
startAfterstringNoCursor for pagination

Example request

curl "https://bridge-hub.example.com/transactions?status=READY_TO_CLAIM&limit=2"

Example response

{
  "data": [
    {
      "hubUID": "tx-0001",
      "sourceNetwork": 1,
      "destinationNetwork": 2442,
      "transactionHash": "0xabc123...",
      "blockNumber": 19500000,
      "timestamp": 1710000000,
      "leafType": "ASSET",
      "originTokenNetwork": 1,
      "originTokenAddress": "0x0000000000000000000000000000000000000000",
      "receiverAddress": "0xdef456...",
      "fromAddress": "0x789abc...",
      "amount": "1000000000000000000",
      "depositCount": 42,
      "leafIndexForProof": 42,
      "globalIndex": "42",
      "status": "READY_TO_CLAIM",
      "lastUpdatedAt": 1710000300,
      "claimTransactionHash": null,
      "claimBlockNumber": null,
      "claimTimestamp": null
    }
  ],
  "nextStartAfterCursor": "eyJsYXN0SWQiOiJ0eC0wMDAxIn0="
}

Response fields

FieldTypeDescription
hubUIDstringUnique business key for the transaction
sourceNetworknumberSource chain ID
destinationNetworknumberDestination chain ID
transactionHashstringSource transaction hash
blockNumbernumberBlock number on the source chain
timestampnumberUnix timestamp of the bridge event
leafTypestringASSET or MESSAGE
originTokenNetworknumberNetwork ID where the token originates
originTokenAddressstringToken contract address on the origin network
receiverAddressstringAddress that will receive funds on destination
fromAddressstringSender address on the source chain
amountstringTransfer amount (BigInt encoded as string)
depositCountnumberDeposit counter from the bridge event
leafIndexForProofnumberLeaf index in the merkle tree
globalIndexstringGlobal index (encoded as string)
statusstringBRIDGED, READY_TO_CLAIM, or CLAIMED
lastUpdatedAtnumberUnix timestamp of last status update
claimTransactionHashstring or nullClaim transaction hash (populated after claim)
claimBlockNumbernumber or nullBlock number of the claim transaction
claimTimestampnumber or nullUnix timestamp of the claim

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

ParameterTypeRequiredDescription
sourceNetworkIdintegerYesSource chain network ID
depositCountintegerYesDeposit counter from bridge event
leafIndexintegerYesLeaf index in merkle tree

Example request

curl "https://bridge-hub.example.com/claim-proof?sourceNetworkId=1&depositCount=42&leafIndex=42"

Example response

{
  "proof_local_exit_root": ["0x...", "0x..."],
  "proof_rollup_exit_root": ["0x...", "0x..."],
  "l1_info_tree_leaf": {
    "l1InfoTreeIndex": 100,
    "rer": "0x...",
    "mer": "0x...",
    "innerBlock": 19500000,
    "innerTimestamp": 1710000000
  },
  "bridge_tx_metadata": "0x..."
}

Response fields

FieldTypeDescription
proof_local_exit_rootstring[]Merkle proof siblings for the local exit root
proof_rollup_exit_rootstring[]Merkle proof siblings for the rollup exit root
l1_info_tree_leafobjectL1 info tree leaf data used in claim verification
bridge_tx_metadatastringEncoded metadata for the bridge transaction

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

curl "https://bridge-hub.example.com/token-mappings"

Example response

{
  "data": [
    {
      "originNetwork": 1,
      "originTokenAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
      "wrappedTokenAddress": "0x37eAA0eF3549a5bB7D431be78a3D99BD6fd6b57D",
      "destinationNetwork": 2442
    }
  ]
}

GET /token-metadata

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

Example request

curl "https://bridge-hub.example.com/token-metadata"

Example response

{
  "data": [
    {
      "tokenAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
      "networkId": 1,
      "name": "USD Coin",
      "symbol": "USDC",
      "decimals": 6
    }
  ]
}

GET /health-check

Returns the service health status.

Example request

curl "https://bridge-hub.example.com/health-check"

Example response

{
  "status": "success",
  "data": {
    "status": "success",
    "message": "All services are working correctly"
  }
}

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.
# First page
curl "https://bridge-hub.example.com/transactions?limit=50"

# Next page (using the cursor from the previous response)
curl "https://bridge-hub.example.com/transactions?limit=50&startAfter=eyJsYXN0SWQiOiJ0eC0wMDUwIn0="
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

CodeMeaningDescription
200SuccessRequest completed successfully
400Bad RequestInvalid or missing query parameters
404Not FoundRequested resource does not exist
500Server ErrorAn unexpected error occurred on the server

Error response format

All error responses follow a consistent structure:
{
  "status": "error",
  "message": "Invalid query parameter: status must be one of BRIDGED, READY_TO_CLAIM, CLAIMED"
}
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.