Skip to main content

Current APIONE authentication

These guides use APIONE API Keys. Create a key in key management, then configure authentication for the client’s protocol. The APIONE documentation verified for these guides does not establish a general third-party OAuth PKCE service, so no unverified authorization URL, client ID, or extension command is provided. Use one supported authentication header: Bearer, x-api-key, or x-goog-api-key. Avoid conflicting credentials.

How PKCE works

A PKCE-enabled client creates one-time verification parameters, opens a browser authorization page, and exchanges an authorization code for an access token. Refresh behavior depends on server support and granted scopes. The client and provider must both support the flow. Another platform’s OAuth extension, domain, scopes, and token-storage rules cannot be reused merely by changing the brand name.

Clients that offer only OAuth

Check whether the client also supports Custom endpoint / API Key. If it does, follow its APIONE guide. If it only supports specific providers’ OAuth services, use a client with custom endpoint support instead of entering an APIONE key into that flow. See OpenCode, Pi Coding Agent, Hermes Agent, and OpenClaw.

Before a future OAuth integration

Use APIONE’s officially published issuer, authorization and token endpoints, client_id, redirect URLs, scopes, PKCE method, and revocation rules. For loopback callbacks, verify the network locations of the browser and client. API Keys and OAuth tokens are credentials. Keep them out of prompts, public repositories, and screenshots. APIONE keys are managed in its console; revoking another provider’s OAuth authorization does not revoke an APIONE key.
Integration directory · Choose a model · Troubleshooting