AxeneAxene Docs
API Reference

Authentication

Learn how to authenticate with the Axene Mailer API using API keys, JWT cookies, or OAuth.

All Axene Mailer API requests require authentication. There are three methods depending on your use case.

Best for server-to-server communication, scripts, and CI/CD pipelines.

Create an API key at Settings → API Keys, then send it as a Bearer token:

curl https://mail.axene.io/v1/emails/ \
  -H "Authorization: Bearer axm_k_YOUR_API_KEY"

API keys use the axm_k_ prefix and carry a set of permission scopes. See API Keys for details on creating, scoping and managing keys.

When you sign into the Axene Mailer dashboard via Google or GitHub OAuth, the server issues a JWT stored in an HttpOnly, Secure, SameSite=Strict cookie. The browser sends this cookie automatically with every request.

You do not need to manage JWT cookies manually. This method is used internally by the dashboard frontend.

The JWT also carries your active workspace, so dashboard requests are automatically scoped to the workspace you are viewing. Besides Google and GitHub OAuth, the dashboard also supports magic-link sign-in and optional two-factor authentication.

OAuth flow

  1. User visits /auth/google or /auth/github.
  2. Axene redirects to the OAuth provider.
  3. Provider redirects back with an authorization code.
  4. Axene exchanges the code for a user profile.
  5. Axene creates or updates the local user record.
  6. Axene issues a JWT and sets it as an HttpOnly cookie.
  7. User is redirected to the dashboard.

JWT details

PropertyValue
AlgorithmHS256
Access token lifetime60 minutes
Refresh token lifetime30 days
Cookie flagsHttpOnly, Secure, SameSite=Strict

Method 3: OAuth (AI assistants / MCP)

Axene Mailer is also an OAuth 2.1 authorization server, used by AI assistants that connect through the MCP server.

A client registers via Dynamic Client Registration (RFC 7591) and runs the authorization-code flow with PKCE. The user signs in and approves the connection on a consent screen; the client receives a short-lived mcp_access token. The API accepts that token in the same Authorization: Bearer header as an API key.

Discovery metadata is published at:

  • /.well-known/oauth-authorization-server
  • /.well-known/oauth-protected-resource (served by the MCP server)

Each connection is recorded as a grant. Revoking it from Settings → Connections in the dashboard invalidates the token immediately. You normally never set this up by hand - your AI client runs the whole flow. See the MCP server guide.

Which method to use

ScenarioMethod
Backend sending emailsAPI Key
Script or CLI toolAPI Key
CI/CD pipelineAPI Key
Browser-based dashboardJWT Cookie (automatic)
Custom frontend calling Axene APIAPI Key (from your backend, not the browser)
AI assistant / MCP clientOAuth (or an API key)

Never expose API keys in client-side code (browser JavaScript, mobile apps). Always proxy API calls through your own backend.

Error responses

StatusMeaning
401 UnauthorizedNo token provided, or the token is invalid/expired.
403 ForbiddenToken is valid but you do not have permission for this action (e.g. admin-only endpoint, plan limit reached).

401 example:

{
  "detail": "Invalid or expired token"
}

403 example:

{
  "detail": "This feature requires the Starter plan or above"
}

If you receive a 401 error with a valid API key, check that the key has not been revoked and that you are including the Bearer prefix in the Authorization header.

On this page