Skip to main content
The MCP server does not accept abi_sk_ API keys. They are separate credentials for separate surfaces, and mixing them up is the most common integration mistake. Sending an API key as a Bearer token to the MCP server fails at the proxy.

OAuth for MCP (current)

This is the credential for every new integration. You do not create, copy, paste, or store anything: a compatible assistant discovers the authorization server, registers itself, and walks the user through sign in. Grants are authorization_code and refresh_token, the code challenge method is S256, and the scope is full_access. Client authentication may be client_secret_post, client_secret_basic, or none for public clients. The full walkthrough, including the challenge your client receives on an unauthenticated call, is in Connect via MCP. To end an assistant’s access, revoke it from your Abigail account. The token stops working immediately.

API Key Authentication (legacy)

The /v1/openclaw/* endpoints this key authenticates were retired on 2026-07-18 and return 404. This section is kept for existing integrations and reference. Keys are still issued from Settings for internal use.
Paid legacy endpoints required an API key in the X-API-Key header.

Key format

Example: abi_sk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Using your key

Key lifecycle

  1. Create a key from Settings > API Keys
  2. The raw key is shown once — copy it immediately
  3. Only the SHA-256 hash is stored server-side
  4. Revoke a key anytime from Settings > API Keys
  5. Revoked keys are rejected immediately

Security best practices

Never commit API keys to source control. Use environment variables or a secrets manager.
  • Store keys in environment variables: ABIGAIL_API_KEY=abi_sk_...
  • Rotate keys periodically
  • Use separate keys for development and production
  • Revoke keys immediately if compromised

Error responses

Missing key

Invalid key

Revoked key