bitpontStart / API 1.9
Bitpont API Authentication, Scopes & Access
Configure server-side API access with scoped bearer keys. Understand expiry, revocation, request limits and safe handling of credentials.
Server-side bearer authentication
Send Authorization: Bearer <key> over HTTPS. Access is provisioned by the operator; Bitpont does not offer self-service keys, billing or a public uptime SLA. Keys can have expiry, revocation and specific scopes. Never place a real key in a URL, HTML snippet, public collection, source repository or browser storage.
Request the smallest useful scope
| Scope | Purpose |
|---|---|
discovery:read | Market resources, catalogues and workflow starters |
positions:read | Account and position reads, portfolio plans, transaction status |
quotes:read | Supported EVM swap comparisons |
transactions:prepare | Unsigned Safe payment and lending preparation |
workflows:prepare | Workflow and composition catalogues and drafts |
The integration manifest and usage endpoint accept any valid key. The manifest reports authorization for each capability without expanding that key’s privileges.
Budgets and response limits
Partner keys default to 60 units per minute, configurable per key. Free access has separate shared limits described in the free API guide. A single request uses one unit; a read batch uses one unit per item. Inspect RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset. A 429 response includes Retry-After.
Read batches contain at most six items. Adapter concurrency is capped at three per key and eight per process. Each adapter response is limited to 1 MiB; adapter timeout defaults to 25 seconds. Counters reset on process restart and are not a billing record.
Rotate and revoke without changing wallet permissions
Ask the operator to issue a replacement key, deploy it server-side and revoke the previous key. API key revocation does not revoke existing wallet allowances or Safe approvals. Those permissions must be managed through their wallet or protocol controls.