Skip to main content
Antideploy uses bearer tokens. There are two kinds, and the difference is what they are allowed to create.
If an agent is doing the work, you want an account token: it can create the project itself, so nothing has to be copied out of a browser. See Terminal login.

​
Project keys

A key is issued for a single project and can only act on that project. There are no permission scopes to choose between.
This is deliberate. A key pasted into a project directory ends up in more places than its owner intends: a shell history, a config file, a commit. The blast radius of that should be one application, not an account.

​
Creating a key

Keys are created in the dashboard, per project:
1

Open the project

Choose the project from the switcher, then open API keys.
2

Create a key

Give it a name that says where it will live: laptop, ci, claude-code. The name is only for you.
3

Copy it now

The secret is shown once, at creation. It is stored as a hash, so it cannot be recovered afterwards, including by us. If you lose it, revoke it and make another.
Creating a project through New project → API issues its first key in the same step.

​
What a project key can do

Because the key identifies the application, requests made with one never send an application id.

​
Account tokens

An account token represents you rather than a project, which is what lets an agent create an application and deploy to it unattended. You get one by approving a browser prompt once. See Terminal login for the full flow.

​
What an account token can do

Requests must name the application: ?applicationId=<id>.
Keep an account token out of your project directory. ~/.antideploy/config.json with mode 0600, or your agent’s own credential store. A project key is built to survive being committed; this one is not.
That last row matters more than it looks. A credential that can mint its own successors cannot really be revoked, because whoever holds it just makes a replacement faster than you can kill them.
Secrets are write-only over the API, for both credentials. GET /api/v1/secrets returns key names and nothing else. There is no endpoint that returns a value, so a leaked credential cannot be used to exfiltrate what it wrote.

​
Revoking

Open API keys for the project to revoke a project key, or Account tokens to revoke a terminal login. Either stops working immediately; revocation is checked on every request, not cached. Both are browser actions. Neither credential can revoke anything over the API, including itself, because otherwise a stolen one could withdraw the legitimate credentials and leave only the thief holding a working key. Revoke rather than delete: the row is kept so Last used remains visible, which is how you work out whether a leaked credential was actually used.

​
Rotating

There is no in-place rotation. Create the new credential, update wherever the old one lives, confirm the new one has been used, then revoke the old one. Both work during the overlap.

​
Pointing an AI agent at Antideploy

Give it this URL and nothing else:
It explains the whole path from an empty terminal to a live URL, and points at https://antideploy.com/api/v1, which returns the full contract as JSON and needs no credential to read. An agent that has been handed only a credential, with no way to learn what the credential is for, will either guess or refuse, and refusing is the better of those two outcomes.
Do not paste a credential into a chat window. An agent that needs one should run the terminal login and write the token to a file itself: anything pasted into a conversation is in that conversation’s transcript for good.

Deploy over the API

The push flow an agent should follow.