7. SDK keys and secret API keys

First decide whether requests originate from your server or a customer's app. These connections use different keys. Using the wrong key causes authentication failures; putting a server secret in an app or browser exposes its privileges.

Which key should I use?

SDK keys are intended for client use, but do not prove customer account ownership or authorize privileged server operations. A prefix alone is insufficient; copy the key from the correct app record.

Create a secret key

1. Sign in to the dashboard and select your project.
2. Open Apps → API keys.
3. Choose the create action under Secret keys.

4. Enter a descriptive name, such as “Website backend” or “Discount service”.
5. Enable only the required operations in the permission groups; at least one ability is required.

6. Save and securely store the full key on your server immediately.

Team members need key-management permissions. If the project-owner identity requirement blocks creation or use, follow identity verification.

The complete secret is shown only when created. Later listings show a masked value. A lost secret cannot be recovered from that record; issue a replacement and revoke the old key after migration.

Choose secret-key abilities

Abilities are independent: reading customer information does not authorize deletion. A descriptive key name grants no permissions.

A service that only generates discount codes needs discount:generate, not customer deletion or access grants. Use separate keys for independent integrations so revoking one does not disrupt all others.

Authenticate REST API requests

Send the secret as a Bearer token:

Authorization: Bearer YOUR_SECRET_API_KEY
Accept: application/json
Content-Type: application/json

The key determines the project. A key from another project does not access the intended project's records. Offering endpoints also require X-InAppify-App-ID according to their contract, identifying an app in the key's project.

Do not put secrets in URLs, messages, frontend code, or downloadable files. See REST API authentication for complete requests and PHP examples.

Find an SDK key

An SDK key is automatically issued when you create an app; do not create it through the secret-key form.

1. Select the project and open Apps → API keys.
2. Find the correct app name and platform in the app-key table.

3. Reveal and copy the key. Unlike server secrets, app keys can be viewed again here.

4. Supply it during initialization of that app's SDK; use the exact option from your platform's SDK guide.
5. Identify a test customer and test offering retrieval using the SDK connection step.

Use the appropriate app key for Bazaar, Myket, direct Android, iOS, or web. Shared product names or a shared project do not imply shared app keys. Generated prefixes may include bzr_, myk_, andr_, ios_, and web_; these are hints, not usable example credentials.

Do not initialize an SDK with a sk_ server secret or store credentials. The current V1 app API checks the app key in the apikey field; this is different from REST API Bearer authentication. Normally let the SDK handle its requests.

Secure storage and rotation

Store server secrets in server-side environment variables or a secrets manager. A value injected into a browser JavaScript bundle is not secret, even if it originated in an environment variable. Never expose real keys in repositories, logs, error reports, screenshots, or public conversations.

Edit a secret key's name and abilities from the list. Editing does not issue a new secret; subsequent requests must satisfy current abilities. Revoking a key stops subsequent REST API use. Creating a replacement does not automatically revoke the old one.

For planned rotation, issue a minimally scoped replacement, deploy it to the backend, verify connectivity, and revoke the old key. If a key is exposed, prioritize stopping its access: revoke it with awareness of integration downtime, then deploy the replacement securely.

Revoking a server secret does not replace app SDK keys. The current secret-key form has no expiration-date input; schedule revocation for temporary access. The current SDK table also has no independent app-key rotation or revocation control. Do not delete an app merely to rotate its key; contact support for this requirement.

Troubleshooting

• REST API 401: missing, incorrect, or no longer valid secret; check Bearer syntax, the full value, and revocation.
• 403, API_KEY_ABILITY_DENIED: valid key without the required ability.
• 403, PROJECT_OWNER_IDENTITY_REQUIRED: project-owner identity verification is required; replacing the key does not resolve it.
• V1 SDK missing or invalid key: check the correct app SDK key and request contract; do not substitute a server secret.
• Connected but wrong or empty offerings: check the key's app and project, package products, and offering configuration.

Do not send the key when reporting an issue. Start with the integration name, SDK type, endpoint, status code, and a sanitized error message.

Continue setup

Before testing purchases, prepare store credentials or an active direct-payment gateway. See payment gateways.

Next: Connect the SDK.