# 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.

Canonical: https://www.bitpont.com/developers/errors/


## 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 JavaScriptCopy code
```
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

StatusExamplesResponse

400INVALID_PARAMETERSCorrect the input; do not retry unchanged.

401 / 403UNAUTHORIZED / SCOPE_REQUIREDCheck server key, expiry and granted scope.

429RATE_LIMITEDRespect Retry-After and reduce concurrency.

502 / 503 / 504ADAPTER_UNAVAILABLE / ADAPTER_NOT_CONFIGURED / ADAPTER_TIMEOUTKeep 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.