Configure allowed apps and API keys

Choose the correct integration control#

• Allowed Apps registers a browser host and origin so the platform can accept requests from an approved web application.
• API Keys authenticates server-side REST requests. A raw key must never be embedded in browser JavaScript or a mobile application.
• Many integrations need both a registered browser origin for interactive frontend behavior and a separately protected server credential for backend requests.
• Use the Headless & API guide for request paths and examples after configuration is complete.

Register an allowed application#

1. Open Settings → Apps and API Keys

   In Apps, choose Add App.

2. Enter an identifiable name

   Use a name that describes the application owner and purpose without exposing secrets.

3. Enter host and origin

   Use the exact browser host and origin, including scheme and port where applicable. Do not add path fragments or credentials.

4. Add a safe description

   Describe the expected use and environment without including private tokens or customer data.

5. Save and allow propagation time

   Confirm the entry and status. Registration changes can take roughly 30 minutes to propagate.

Deactivate or remove an application#

1. Identify active consumers

   Confirm which application and environment use the origin before changing it.

2. Deactivate for a reversible stop

   Use the active control to stop acceptance while retaining the record when the interface permits it.

3. Delete only when retired

   Remove the entry after the application has stopped using it and rollback is unnecessary.

4. Test from the intended browser

   Verify the expected application succeeds and an unapproved origin remains blocked.

Create and store an API key#

1. Choose Create API Key

   Enter a name tied to one service or operational purpose and, when appropriate, choose an expiry.

2. Create once

   Submit the form and wait for the one-time secret display.

3. Copy the raw key immediately

   Store it in a server-side secret manager. The full value is not recoverable from the masked list later.

4. Close the secret display

   Confirm the key row shows its name, status, created time, last-used state, and expiry without exposing the raw value.

5. Make a server-side test request

   Send `Authorization: Api-Key YOUR_API_KEY` from a trusted server and use the public API origin supplied for your environment.

Rotate, deactivate, or delete a key#

1. Review last use and consumers

   Identify every service that depends on the key before changing it.

2. Create or regenerate a replacement

   Store the new secret safely and update consumers one at a time.

3. Verify the replacement

   Confirm requests succeed and the new key records expected use.

4. Deactivate the old key

   Use a reversible inactive state first when a rollback window is needed.

5. Delete when no longer needed

   Remove the old key only after all consumers have migrated and rollback is unnecessary.