# Access & permissions Call the API from your backend with a studio key. The key establishes studio authority; your application authenticates its own visitors and decides which actions they may take. ## Inputs and prerequisites Create a key in studio Settings → API keys and store it as a server-side secret. Send `Authorization: Bearer ` over HTTPS. Never embed it in browser code, mobile apps, redirects, URLs or customer sessions. The resolved key determines the tenant. Do not submit a tenant selector. The studio needs current `public_api` access; new commercial writers also require the studio's headless API enablement. Studio-collected commercial entry has an additional platform readiness prerequisite. Ask the studio/platform operator to establish these prerequisites before trial writes. ## Authority is checked on every call Current account activity, key revocation, current key owner/scoped permissions, contextual ownership and conditional permissions apply to reads, writes and recovery. Required route permissions are combined AND requirements, not alternative roles. See each operation's security/permission details in the [API reference](/api/docs). For example, [native booking admission](/api/docs#/Studio%20native%20checkout/v2CheckoutBooking) needs session creation, client reading and payment collection authority; creating a client association can require additional client creation authority. Studio collection uses external-reporting authority. Access to a linked client is checked separately. ## Visitor identity is your responsibility A typed email is a lookup or association input, not proof that the visitor owns the account. A studio key must not become an unrestricted customer proxy. Authenticate the visitor and authorize their access to the requested client, booking or payment in your backend before making the API call. [Creating an external client](/api/docs/guides/v2/clients) does not activate a Podyx login or send an activation invitation automatically. ## Results, effects and recovery Reads do not create credentials or a visitor session. `401 invalid_key` means credentials are missing, invalid or revoked. `403` can indicate account, feature or permission refusal. A resource absent from the current tenant or inaccessible through contextual authorization may return `404 not_found`. Do not retry these errors with a broader key as an automatic fallback. Correct the authorized configuration and apply the [same-intent recovery rules](/api/docs/guides/v2/recovery) if a previous write may have been accepted. Disabling new entry does not grant a bypass around revocation or current permissions. ## Example Read customer-buyable service offers from your backend: ```sh curl --get "https://app.podyx.com/api/v2/services" \ -H "Authorization: Bearer $PODYX_API_KEY" \ --data-urlencode 'view=offers' \ --data-urlencode 'page=1' \ --data-urlencode 'per_page=20' ``` Follow the response's pagination. This call discovers the catalog; it neither signs a visitor in nor grants authority to book for another person.