Gas readiness behind one API.

Register wallets, read gas health, and track every operation without building chain-specific gas infrastructure yourself.

Read the API reference

Business concepts in. Chain and exchange complexity out.

The public API exposes wallets, gas health, policies and their revisions, and gas operations.

It never accepts exchange credentials, withdrawal addresses, transaction payloads, or signing material. Those belong to GasTanker's controlled execution path, not your integration.

Wallets: POST /v1/wallets · GET /v1/wallets
Gas health: GET /v1/wallets/{id}/gas
Policies: GET /v1/policies · /{id} · /{id}/revisions
Gas operations: POST /v1/gas/ensure · GET /v1/gas/operations/{id}

Authentication

Every request uses an organization-owned API key.

Keys are created in the dashboard by a team member who has passed a second-factor check. They're shown once.

HTTP

X-API-Key: gt_...

Live

Example: register a wallet

Request

HTTP

POST /v1/wallets
X-API-Key: gt_...
Idempotency-Key: 4b1e...

{
  "network": "base",
  "address": "0x7a2...",
  "label": "Payouts – EU"
}

Response

JSON

{
  "id": "wal_01...",
  "networkId": "base",
  "address": "0x7a2...",
  "label": "Payouts – EU",
  "verificationStatus": "unverified"
}

Live

Example: check gas health

If GasTanker can't read the balance reliably, health is unknown. It never guesses.

Request

HTTP

GET /v1/wallets/wal_01.../gas

Response

JSON

{
  "balanceBaseUnits": "4200000000000000",
  "health": "low",
  "monitoring": {
    "status": "healthy",
    "lastSuccessfulAt": "2026-10-07T09:15:02Z",
    "consecutiveFailures": 0
  }
}

Live: watch-only

Example: keep this wallet ready

Today the operation records the shortfall and alerts your team. When automatic funding is enabled for your organization, the same call drives the funding workflow without changing your integration.

Request

HTTP

POST /v1/gas/ensure
Idempotency-Key: 9d0a...

{ "walletId": "wal_01..." }

If the wallet is healthy:

JSON

{ "status": "healthy", "operation": null }

If it is low, GasTanker returns the operation it created:

JSON

{
  "id": "gasop_01...",
  "walletId": "wal_01...",
  "observedBalanceBaseUnits": "4200000000000000",
  "requiredBaseUnits": "45800000000000000",
  "status": "awaiting_source_liquidity"
}

Amounts are explicit.

Financial infrastructure should never make developers guess units.

Amounts are exact integer strings in the network's native-asset base units (wei for ETH, lamports for SOL, stroops for XLM, MIST for SUI). No floating point anywhere.

Unit confusion is too expensive to hide behind convenience.

JSON

{ "requiredBaseUnits": "45800000000000000" }

Retrying a request should never mean paying twice.

Every mutation requires an Idempotency-Key. Retry with the same key and you get the original result, not a second operation.

One wallet can have only one active gas operation at a time.

Errors tell you whether you need to act.

Every error says what happened and whether retrying can help.

JSON

{
  "error": {
    "code": "UNSUPPORTED_NETWORK",
    "message": "UNSUPPORTED_NETWORK",
    "retryable": false
  }
}

“Submitted” is not “complete.”

Gas operations expose their lifecycle.

Today: created → validating → awaiting_source_liquidity
With automatic funding · coming soon: … → approved → withdrawing → at relay → forwarding → confirming → reconciled → completed
If GasTanker cannot determine what happened: unknown → resolving
not: failed → retry blindly

Reference

The full contract is published as OpenAPI with an interactive reference. Changes to the public contract are reviewed for compatibility.

Open the API reference