Operate / API 1.9

Bitpont API Errors, Rate Limits & Transaction Recovery

Handle partial reads, rate limits, provider outages and uncertain transaction status. Use request identifiers and bounded retries in Bitpont integrations.

Download page as Markdown ↓

Distinguish a failed request from incomplete data

HTTP 200 does not establish complete data. A read can be available, partial or stale. Batch responses preserve per-item errors. Display unavailable balances as unavailable and retain their identity.

Server-side JavaScript

try {
  for await (const state of bitpont.watchTransaction(
    {network:'base', hash:TRANSACTION_HASH},
    {intervalMs:5000, maxPolls:60, confirmations:2}
  )) console.log(state.data.status, state.data.confirmations);
} catch (error) {
  console.log(error.code, error.requestId);
  // Resume tracking the existing hash. Do not automatically resubmit.
}

Handle errors by code

Status	Examples	Response
400	INVALID_PARAMETERS	Correct the input; do not retry unchanged.
401 / 403	UNAUTHORIZED / SCOPE_REQUIRED	Check server key, expiry and granted scope.
429	RATE_LIMITED	Respect Retry-After and reduce concurrency.
502 / 503 / 504	ADAPTER_UNAVAILABLE / ADAPTER_NOT_CONFIGURED / ADAPTER_TIMEOUT	Keep identity and partial results; apply bounded retry only when indicated.

Send Accept: application/problem+json for RFC 9457 problem details. Keep the request ID for diagnostics. Do not log bearer keys, signed payloads or sensitive account responses.

A transaction hash is a recovery anchor

transactions.status reports not-found, pending, included or reverted for supported EVM networks. Not-found does not establish failure. Inclusion is not proof of a protocol fill, destination delivery or finality.

watchTransaction() polls with a bounded interval, confirmation target and maximum number of reads. A polling limit tells the application to resume tracking the same hash, not submit again.

Operational limits remain explicit

Usage counters are process-local. Hosted webhooks, distributed metering, unattended execution and a public uptime SLA are not included. A partner should test provider outages, empty results, cursor failures, key revocation and interrupted owner review before releasing an integration.