Some things you do once in a user interface, others twenty times a week. That is where automation starts — and often stops right there, because a script or a CI job has no way to sign in. A browser login dialog is no use when nobody is there to click it.
Since 5 August you can create personal API keys for exactly this purpose.
Keys live in your account settings
You manage them from your account settings. That is where you create new keys, review the ones you have and revoke the ones you no longer need.
One detail matters: the secret value is shown once, right after you create the key, and cannot be retrieved again. Copy it straight into wherever it belongs, such as your pipeline’s secret storage or your password manager. If you lose it, create a new key and revoke the old one — deliberate, because a key you can read back at any time is also one anyone with access to your account can read back.
What the keys are for
With an API key, the ap CLI authenticates without a browser sign-in beforehand. The same goes for any script of your own that talks to the platform API. Three cases come up especially often:
- CI/CD integrations — a pipeline that triggers or reads something on the platform after a build
- Recurring jobs — reports, clean-up tasks or exports that run on a schedule
- Internal tooling — small command line programs or interfaces that work with platform data
What these have in common is that no human is present when they run. That is precisely the gap the keys fill.
Pipeline for Customer App
The tools around them
API keys are not the only way to work outside the web interface. There is a Platform App for the desktop, the ap CLI for the terminal, a plugin for VS Code, and an MCP server that lets AI coding agents talk to the platform.
Handling keys sensibly
Create one key per purpose: one for the CI pipeline, one for your local tooling, one for the nightly job. If a key has to be replaced, only that single use is affected.
Do not share keys. They are personal, and whatever happens with them is attributed to you. If a colleague needs access, that colleague creates their own key. If a key ends up somewhere it should not be, revoke it and issue a new one — and keep the classic in mind: keys do not belong in a repository, not even briefly for testing.
Related topics
Personal API keys are the entry point for everything that should run without going through the interface, and they keep responsibilities clearly separated: each key belongs to one person and one purpose.
For a picture of automated workflows on the platform, see CI/CD automation. Endpoint details are in the documentation.
