> ## Documentation Index > Fetch the complete documentation index at: https://docs.sendlyy.app/llms.txt > Use this file to discover all available pages before exploring further. # Authentication and tenant isolation > Independent organization service keys, scoped to your application. Send credentials in the Authorization header: ```http theme={null} Authorization: Bearer sk_live_. Content-Type: application/json ``` A key belongs to exactly one organization, project and environment. Dedicated-number operations also require explicit sender grants. The server resolves the organization from the stored credential, verifies its secret hash and checks its current expiry, revocation and resource status. Never put keys in a browser, mobile binary, widget, query string or public repository. You normally do not send `X-Organization-Id` with a service key. Supplying another organization's ID does not change the key's authority and is rejected. Organization and project identifiers in a request are selectors, never proof of permission. | Scope | Access | | - | - | | `messages:send` | Dedicated template sends; explicit sender grants required | | `messages:read` | Dedicated granted-sender metadata and Notify message metadata | | `templates:read` / `templates:write` | Dedicated granted-sender templates and project Notify templates | | `senders:read` | Granted dedicated numbers | | `contacts:read` / `contacts:write` | Project contacts, consent, lists and segments | | `verify:send` / `verify:check` | Start verifications / check codes and retrieve status | | `notify:send` | Shared transactional notification sends | | `usage:read` | Scoped usage, retail quotes and seven-day request metadata | | `webhooks:manage` | Scoped subscriptions, signing-secret rotation and delivery metadata | The issuing human cannot grant permissions beyond their current grants. Once issued, keys are independent service credentials: removing their creator from the organization does not revoke them. Revoke or rotate the key explicitly. Suspension of the organization, project archival or environment deactivation prevents authentication. Workers recheck service-key and resource authority before dispatch. Secrets are shown once at creation and rotation. Rotation immediately invalidates the previous secret. Use separate keys for distinct services and environments and supply an expiry where appropriate. There are no AI service-key scopes. ### Human setup versus service calls Organization onboarding, project creation, key issuance/rotation/revocation, wallet funding, Meta connection and rental requests are management operations. They use authenticated customer sessions, CSRF protection, RBAC and recent MFA where required, rather than a service key. Superadmin operations use separate staff roles. These management endpoints are deliberately excluded from this developer reference. Operators can use the complete internal OpenAPI and `docs/BACKEND_HANDOFF.md` during provisioning. Do not automate customer setup with copied staff cookies or distribute management cookies to application servers. ### Project and environment boundaries Message sends, verifications, Notify, usage and webhooks enforce the key's environment. Contacts and template definitions are project resources shared between that project's Sandbox and Live environments. A Sandbox key cannot use a Live environment ID to send real messages or charge a wallet. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.