Skip to main content

Projects and API Keys

A workspace in the Appilots dashboard can hold multiple projects. Each project is what a single SDK or CLI integration points at — identified by a projectId and authenticated with an API key scoped to that project.

What you can do here depends on your role in the workspace (owner, admin, member, or viewer). See Team management for what each role can do — this page doesn't redefine them.

Creating a project​

  1. From the dashboard, open the project list for your workspace.
  2. Click to create a new project.
  3. Give it a name and a short description.
  4. Save. The project now has its own settings, API keys, and configuration, independent of every other project in the workspace.

Most teams create one project per app — for example, separate projects for two different mobile apps sharing a workspace — so permissions, budgets, and usage stay scoped per app.

API keys​

Each project has its own API key(s). A key is what your app build or CLI invocation uses to authenticate as that project — see CLI configuration and SDK: AppilotsProvider for where the projectId and API key pair is actually consumed.

Creating a key​

When you create a new API key for a project, it looks something like ak_xxxxxxxxxxxx... and is shown in full only once, at the moment you create it. Copy it immediately and store it somewhere safe (a secrets manager, your CI provider's encrypted variables, and so on).

If you lose a key, there's no way to view it again — you'll need to revoke it and issue a new one.

Scope​

An API key is scoped to a single project. A key created for Project A cannot authenticate against or access Project B's data, even within the same workspace.

Revoking a key​

Revoking a key takes effect immediately: no new request will authenticate with that key afterward. Connections that were already open at the moment of revocation may be allowed to finish, but nothing new will be accepted.

Revoke a key whenever it's exposed, when a team member with access to it leaves, or as part of routine rotation.

  • One key per environment. Use separate keys for staging and production builds (and for each app, if a project serves multiple apps) so you can revoke one without disrupting the others.
  • Rotate periodically. Treat API keys like any other long-lived credential — rotating them on a schedule limits the blast radius if one ever leaks.
  • Never hardcode keys in a public repo. Load them from environment variables or your CI's secret store instead.

See Security best practices for a fuller checklist covering keys, permissions, and webhook secrets together.

Next steps​

Last updated on