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

# API quickstart

> Authenticate backend requests to the hosted Athena API.

Use the Athena API from a trusted backend. API keys identify the organization context of the request and must not be included in browser code, mobile app bundles, workflow prompts, or support tickets.

## Authenticate

Create an API key from your organization's **API Keys** page and store it in your backend's secret configuration. The hosted API origin is `https://athena.tryopencomputer.com`; API paths begin with `/api/v1`.

```bash theme={null}
export ATHENA_BASE_URL="https://athena.tryopencomputer.com"
# Provide ATHENA_API_KEY through your application's secret configuration.
curl --fail-with-body "$ATHENA_BASE_URL/api/v1/auth/me" \
  -H "X-API-Key: $ATHENA_API_KEY"
```

The identity endpoint reports the authenticated user and selected organization. If you receive an unexpected organization, confirm which key your backend loaded before creating resources.

## Make a request

Send JSON bodies with `Content-Type: application/json`. Use the method, exact path, and request fields shown for the endpoint. Some collection paths include a trailing slash; preserve the path from the API reference when you construct a request.

For example, to start a phone call, use the public agent trigger route and `X-API-Key`. See [Trigger a phone call](/guides/calls.md) for the endpoint choices and request fields. A phone call can be placed by either a published or `/test/` route, so test only with a controlled destination.

API keys and inference service keys are different resources. Use `X-API-Key` for customer API requests; do not substitute an inference service key.

## Read errors carefully

Inspect the HTTP status, response content type, and body. API error responses commonly use a `detail` field; validation errors can contain structured entries rather than a single message.

| Status | Common interpretation |
| - | - |
| `401` | Authentication is missing or invalid. |
| `403` | Access is forbidden. An edge-generated HTML response may indicate a request was blocked before reaching the API. |
| `404` | The resource is absent, unavailable to this caller, or the feature is disabled. |
| `409` | The request conflicts with current state, such as a duplicate name, stale session revision, or in-progress turn. |
| `422` | The request fields are invalid or workflow validation failed. |
| `429` | A rate or concurrency limit was reached on a route that enforces one. |

Do not treat every `403` as an API-key failure: check whether the response is API JSON or an edge-generated page. Likewise, a `404` for an optional feature can indicate that the feature is disabled for the deployment.

## Avoid duplicate actions

Do not blindly retry a call-trigger POST after a timeout or lost response. The call may already have started. Look for the run using the ID from the response or the agent's run list before sending another request. The same caution applies to requests that start a text session or execute a tool. See [Calls, runs, and results](/guides/runs.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.