> ## Documentation Index
> Fetch the complete documentation index at: https://antideploy.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# API Authentication: Project Keys

> How Antideploy API keys work: one key per application, how to create and revoke them, and what a leaked key can and cannot do.

Antideploy uses bearer tokens. One key, one application.

```bash theme={null}
curl https://antideploy.com/api/v1/deployments/$TASK_ID \
  -H "Authorization: Bearer $ANTIDEPLOY_KEY"
```

## One key, one application

A key is issued for a single project and can only act on that project. There
are no account-wide keys, no organization keys, and no permission scopes to
choose between.

<Note>
  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.
</Note>

## Creating a key

Keys are created in the dashboard, per project:

<Steps>
  <Step title="Open the project">
    Choose the project from the switcher, then open **API keys**.
  </Step>

  <Step title="Create a key">
    Give it a name that says where it will live: `laptop`, `ci`,
    `claude-code`. The name is only for you.
  </Step>

  <Step title="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.
  </Step>
</Steps>

Creating a project through **New project → API** issues its first key in the
same step.

## What a key can do

|                                                                |        |
| -------------------------------------------------------------- | ------ |
| Deploy to its application                                      | Yes    |
| Read deployment status, logs of progress, warnings and hazards | Yes    |
| Write environment variables                                    | Yes    |
| **Read environment variable values**                           | **No** |
| Act on any other application                                   | No     |
| Create, rename or delete applications                          | No     |

<Warning>
  Secrets are **write-only** over the API. `GET /api/v1/secrets` returns key
  names and nothing else. There is no endpoint that returns a value, so a leaked
  key cannot be used to exfiltrate the credentials it wrote.
</Warning>

## Revoking

Open **API keys** for the project and revoke the key. It stops working
immediately; revocation is checked on every request, not cached.

Revoke rather than delete: the row is kept so `Last used` remains visible,
which is how you work out whether a leaked key was actually used.

## Rotating

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

## Handing a key to an AI agent

Give the agent the key **and** this URL:

```
https://antideploy.com/api/v1
```

It returns the whole API contract as JSON and needs no key to read it. 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.

<Card title="Deploy over the API" icon="rocket" href="/docs/api/deploy">
  The push flow an agent should follow.
</Card>