# Authentication and API keys

Source: https://docs.oiy.ai/docs/api/authentication

Use account-scoped keys without exposing credentials to your workloads.



## Console authentication [#console-authentication]

The console supports email/password and Google sign-in. Email verification is required for new compute allocation and API key creation. Owners can still stop or delete existing resources and revoke keys without introducing a new allocation.

## API keys [#api-keys]

Create a key in console Settings using a verified, interactive sign-in and store it securely. A personal API key cannot create another key. An account can have at most 20 active keys. Supply it as `Authorization: Bearer …` on account requests. Keys are account-scoped and revocable. They do not grant administrator privileges.

Use a distinct key for an integration when you want independent revocation. Never publish keys in a browser bundle, image, repository, notebook output, or command argument.

## Scoped instance activity [#scoped-instance-activity]

Oiy-managed instances receive a service-scoped task token. It authorizes activity tracking for that service, not general account operations. Prefer the injected activity credentials for task protection rather than a personal API key.

## Account endpoints [#account-endpoints]

| Method | Path             | Result                                                             |
| ------ | ---------------- | ------------------------------------------------------------------ |
| GET    | `/api/me`        | Current authenticated identity                                     |
| GET    | `/api/account`   | Balance, services, volumes, and ledger snapshot                    |
| GET    | `/api/keys`      | API key metadata                                                   |
| POST   | `/api/keys`      | Create an API key; verified interactive Firebase identity required |
| DELETE | `/api/keys/{id}` | Revoke a key                                                       |

The console handles key creation fields and displays the new credential. Store it when issued; later listing does not return the secret value.

## Authentication failures [#authentication-failures]

Check that the key has not been revoked, the request targets the expected HTTPS origin, and the resource belongs to the same account. Keep credentials out of redirects to another origin.

## Key creation contract [#key-creation-contract]

`POST /api/keys` accepts `{ "name": "My integration" }`. The trimmed name is 1–64 characters. The response is a bare object containing `id`, `name`, and the new secret `token`, with HTTP `201`.

Listing returns `{ "keys": [...] }`, with `id`, `name`, `prefix`, and `created_at` for each active key. `created_at` is Unix milliseconds. Revocation returns `{ "ok": true }`; it does not return a credential.

## Account snapshot boundaries [#account-snapshot-boundaries]

The account snapshot returns `balanceMicros`, `currency`, `services`, `volumes`, and `ledger`. Services and volumes omit deleted resources. The ledger includes at most the 100 most recent entries, not a complete billing export. Use the [billing history endpoints](/docs/api/billing) for complete-window totals and paginated history. Each entry includes its signed `deltaMicros`, resulting `balanceMicros`, kind, reason, actor, timestamp, and optional service association.

The console and service-scoped task credentials are separate authentication mechanisms. Never substitute a task token for a personal account key.