Understand API tenant isolation
This guide explains that all returned records are restricted to the authenticated tenant. 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.
Where to goEnterprise POS → Settings → Scoped API credentials
What you’ll accomplish
Know all returned records are restricted to the authenticated tenant. 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 tenant isolation”. 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: Know all returned records are restricted to the authenticated tenant.
- 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.
Continue with related guidance
Was this guide useful?Your response is stored only in this browser.
