Read-only API credentials and endpoints

Understand API rate limits

Follow this guide to use 600 requests/hour per key+IP for business endpoints and 120/hour/IP for health. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

Audience: Integration administrators and developersPermission: Enterprise POS: Manage settings; bearer scopes at runtimeModule v1.0.0 · code-inspected

Jump to steps

Where to goEnterprise POS → Settings → Scoped API credentials

What you’ll accomplish

Use 600 requests/hour per key+IP for business endpoints and 120/hour/IP for health. This section documents API key creation, authentication, rate limits, list parameters and every supplied GET endpoint.

Follow these steps

Go to Enterprise POS → Settings → Scoped API credentials and open the workflow that matches “Understand API rate limits”. Confirm the page or record context before making a change.
Create a named API key with the minimum read scopes and optional expiry.
Copy the full bpos_ secret once.
Send it as an Authorization: Bearer header over HTTPS.
Call only the endpoint matching the granted scope.
Handle 401, 403, 404, 422 and 429 responses safely.
Revoke the key when no longer needed.

Fields and options to review

Guide focus: Use 600 requests/hour per key+IP for business endpoints and 120/hour/IP for health.
Key name, scopes and optional expiry
One-time secret and stored prefix/hash
catalogue:read, inventory:read, orders:read, reports:read
limit 1–100 and offset
Bearer authorization
Key/IP rate-limit identity

Rules the system enforces

All supplied business endpoints are GET/read-only.
Secrets begin bpos_ followed by 48 hexadecimal characters.
Business API limit is 600 requests per hour per key+IP.
Health limit is 120 requests per hour per IP.
List limit is clamped to 1–100.
reports:read can be assigned, but version 1.0.0 has no reports API route.

How to confirm it worked

The specific outcome described by this guide is visible and remains tenant-scoped.
Valid scoped calls return tenant-filtered JSON.
last_used_at is updated for authenticated keys.
Revoked/expired/wrong-scope keys are rejected.

Safety checks and troubleshooting

Transmit keys only over HTTPS.
Store the one-time secret in an approved secret manager.
Use separate least-privilege keys per integration.
Never put API secrets in URLs or client-side JavaScript.

Stay within the supported module flow

Use the supplied UI, host module lifecycle and documented endpoints. Do not bypass tenant filters, permissions, CSRF, idempotency, rate limits, audit evidence or transaction checks. A stored table or field does not imply that version 1.0.0 exposes a management screen for it.

Was this guide useful?Your response is stored only in this browser.