Skip to main content

Register with AIGW

AIGW exposes a Dynamic Client Registration endpoint so an agent can obtain its own OAuth client credentials at runtime.

Registration request​

Send the request to the registration_endpoint returned by discovery. Register a confidential agent client with:

POST https://api.aigw.loginid.ai/api/register
Content-Type: application/json

{
  "client_name": "My agent",
  "redirect_uris": ["https://agent.example.com/callback"],
  "token_endpoint_auth_method": "client_secret_post"
}

Registration requirements​

  • Redirect URIs must be absolute HTTPS URLs; all callbacks in one registration must share a host.
  • Domain verification requirements depend on deployment configuration. A registration without accepted evidence can return verification_method: none; an operator requiring a verified domain can refuse access.
  • Choose the resource scope later, in the authorization request.
Don't send resource scopes at registration

Do not include resource scopes in the DCR request. AIGW filters non-registrable scopes out of the registration; registration does not grant merchant access.

Registration response​

See the complete 201 response and field definitions. A successful request includes:

  • client_id;
  • client_secret;
  • client_secret_expires_at: 0 when the secret has no configured expiry;
  • default granted scope string;
  • redirect-host/domain information;
  • verification method;
  • core AIGW issuer/endpoints.

For the confidential client_secret_post registration above, the secret is returned only at creation. Persist it securely and reuse the client instead of registering on every authorization. AIGW also supports client_secret_basic, public none clients with PKCE, and private_key_jwt clients with an inline public jwks. Public/asymmetric registrations do not receive a shared secret. Use the authentication method granted in the response.

Agent approval​

The first time a newly registered agent asks for a Resource, the Resource's effective Agent policy decides its status. By default every agent is Approved automatically. A Project can instead hold agents for review — they then appear under Agents → Pending, and authorization is refused until the project operator approves or rejects them — or reject them outright.

Proving who your agent is can earn a more open decision when the operator has configured it: AIGW recognizes proofs such as a platform-trusted domain, Web Bot Auth request signatures, reverse DNS, a KYA credential from an accepted issuer, and hosted client metadata (CIMD).

If authorization fails immediately after successful DCR, ask the project operator to check the agent's status and the Project's Agent policy before debugging PKCE or the user login flow.

Continue to Request authorization.