Skip to main content

Register Client

POST 
/v1/open-api/oauth/register

Dynamic client registration (RFC 7591). An MCP client that has no client_id of its own — Claude, for instance — calls this endpoint to obtain one before starting the authorization flow. It is intentionally open: the client has no credentials yet, which is the whole point of the endpoint.

A client created here is deliberately the least privileged one the system can express:

  • it is public — no client_secret is issued and none can be, so PKCE is mandatory on /oauth/authorize and /oauth/token;
  • it can hold exactly one grant, PERMISSION_OPEN_API_MCP:READ, whatever scope the request asked for — it can never reach leads, contracts or payments;
  • every redirect_uris entry must be HTTPS, carry no fragment, and belong to an allow-listed host. A URI outside that list is rejected.

Registration alone grants no access: no company data is reachable until an employee approves the client on the consent page.

Repeat calls are idempotent by client_name. Registering again under a name this client already used returns the existing client_id and merely adds any new redirect_uris — a client that re-registers on every retry does not accumulate rows. A request with no client_name is stored as MCP client.

The server decides the response, not the request: grant_types, response_types, token_endpoint_auth_method and scope always come back with the server's values even when the request asked for something else (RFC 7591 §3.2.1). Fields the flow does not use (contacts, policy_uri, tos_uri, jwks, …) are accepted and ignored.

Requires no token.

Request​

Responses​

The client was registered (or an existing one under the same name was returned).