generated: '2026-08-11' method: searched source: https://cubbystorage.github.io/docs/api/#authentication docs: https://cubbystorage.github.io/docs/api/#authentication description: >- Cubby runs two distinct authentication models on one host. The Operator and Storefront APIs use a long-lived, out-of-band-issued API key presented as an HTTP bearer token, scoped to an Organization and further constrained by one of eight named key roles plus a separate PII entitlement. The MCP server on the same host uses OAuth 2.1 with PKCE and dynamic client registration. There is no self-service credential issuance for the REST surface — keys are obtained by emailing support. schemes: - id: operator_api_key type: http scheme: bearer in: header header: Authorization format: 'Bearer ' applies_to: - Cubby Operator API - Cubby Storefront API issuance: >- Out of band. "In order to obtain an API key, please contact support@cubbystorage.com." API access additionally requires an executed Order under the Cubby API Terms of Service, so the credential is commercially gated, not self-service. contact: support@cubbystorage.com rotation: not documented expiry: not documented self_service: false scoping: >- Credentials attach conceptually to the Organization and carry access to all resources (managers, facilities, customers, leases) visible to that Organization. note: >- The storefront web components take the same key as a `data-api-key` attribute on a