Tenant-scoped API keys
Authenticate with `Authorization: Bearer` or `X-API-Key`; tenant identity is resolved from the key, not request payloads.
The current external API is a secure foundation for tenant-scoped integrations. Start with the health endpoint, wire up key management, and use the documented scopes to plan upcoming menu, order, table, service request, and notification workflows.
Authenticate with `Authorization: Bearer` or `X-API-Key`; tenant identity is resolved from the key, not request payloads.
Raw API key secrets are never stored. Persisted hashes are derived with `API_KEY_PEPPER`.
Responses expose fixed-window limit, remaining, and reset headers for integration backoff logic.
Available docs
The public API surface is intentionally narrow today. These pages document what is implemented and call out what is reserved for future endpoint releases.
Verify authentication, tenant resolution, API key mode, logging, and rate-limit headers.
Use the current `/api/v1` foundation safely and prepare for future menu, order, table, and notification endpoints.
Configure secrets, create key records, register allowed origins, test calls, and monitor Firestore logs.
Quick start
This is the currently implemented public endpoint. It validates the key, resolves the tenant, writes an audit row, and returns rate-limit metadata.
Full endpoint referencecurl -H "Authorization: Bearer sk_test_<keyId>_<secret>" \
https://your-domain.com/api/v1/health