How to get platform credentials

​

Choose a registration method

​

Pre-registration (recommended)

​

Provide to Clink

• Application name, technical contact, and target merchant scenarios.
• Deployment information for Sandbox UAT and Production.
• The fixed HTTPS redirect_uri used for first-time user authorization. Required for MCP and RESTful API; not required for Vault SDK.
• The integration methods and capabilities you plan to use. Clink registers scopes accordingly; see the table below.
• Recommended: the platform RSA public key. See Register an RSA public key.

​

Issued by Clink

​

Register an RSA public key

• MCP’s get_credential and the RESTful API’s POST /agent/platform/credential both use this public key. Vault SDK does not need it.
• For the RESTful API, if no public key is registered and the server has not enabled plaintext mode, the credential endpoint returns 71211012 (credential_public_key_not_configured). Registration is recommended for Production.
• Keep the private key only in trusted platform components. For decryption, see Encrypted credential decryption.

​

Store credentials

• CLINK_CLIENT_ID and CLINK_CLIENT_SECRET. If you also integrate Vault SDK, store a separate set of Vault credentials.
• The exact redirect_uri registered for the platform.
• The RSA private key (if you registered a public key).

​

CIMD

{
  "client_id": "https://agent.example.com/.well-known/oauth-client.json",
  "client_name": "Example Agent",
  "redirect_uris": ["https://agent.example.com/oauth/clink/callback"],
  "token_endpoint_auth_method": "none",
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "scope": "wallet:read wallet:setup payment:execute instruction:read instruction:write refund:read refund:write events:read events:consume offline_access"
}

• The URL uses HTTPS and includes a path, with no query or fragment.
• The client_id in the file exactly matches the file URL.
• The URL returns HTTP 200 directly with Content-Type set to application/json. Clink does not follow redirects.
• The file is no larger than 5 KB and contains no secrets.

​

DCR

POST {registration_endpoint}
Content-Type: application/json

{
  "client_name": "Example Agent",
  "redirect_uris": ["https://agent.example.com/oauth/clink/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none",
  "scope": "wallet:read wallet:setup payment:execute instruction:read instruction:write refund:read refund:write events:read events:consume offline_access"
}

​

Common rules for CIMD and DCR

• Both are public clients without a client_secret, and must use Authorization Code + PKCE (S256).
• The registered scopes are the upper limit for every later authorization request. Requests that exceed them return invalid_scope, so register every scope the Agent might use.
• Register only once per deployment, tenant, or installation, and reuse the same client_id for all users.
• Without a client_secret, you cannot call /platform/sessions. After you get a client_id, initiate user authorization yourself, as described below.

​

Initiate user authorization

1. Read {API_BASE_URL}/.well-known/oauth-protected-resource/mcp and get the issuer from authorization_servers.
2. Read {issuer}/.well-known/oauth-authorization-server to get authorization_endpoint and token_endpoint. Do not hard-code the endpoints.
3. Generate and temporarily store state and a PKCE code_verifier for the current user, and compute code_challenge with S256.
4. Redirect the user to authorization_endpoint, with all parameters URL-encoded:

response_type=code
client_id={CLIENT_ID}
redirect_uri=https://agent.example.com/oauth/clink/callback
scope=wallet:read payment:execute instruction:read instruction:write events:read events:consume offline_access
resource={MCP_URL}
state={RANDOM_STATE}
code_challenge={S256_CODE_CHALLENGE}
code_challenge_method=S256