OAuth 2.0 client credentials for partner/v1

The grant, step by step

Client credentials is the machine-to-machine OAuth grant: there is no user in the loop, so no browser redirect and no authorisation code. Your server holds a client_id and client_secret, posts them to the token endpoint, and receives an access token it uses until the token expires — then it repeats. Keep the secret on the server only; it must never reach a browser or mobile client.

Mint a token at POST /partner/v1/oauth/token:

Requesting a token

curl -s -X POST https://hub.credicorp.co.uk/partner/v1/oauth/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d grant_type=client_credentials \
  -d client_id=$CREDICORP_CLIENT_ID \
  -d client_secret=$CREDICORP_CLIENT_SECRET \
  -d scope='applications:write decisions:read'

The response is a bearer token with an expiry (expires_in, in seconds) and the granted scope. Cache it and reuse it until shortly before expiry rather than minting one per request — the token endpoint is itself rate-limited.

Using and verifying the token

Send the token on every partner call as Authorization: Bearer <access_token>. Tokens are signed JWTs; if you want to verify them yourself — for instance in a resource server of your own — fetch the public keys from the JWKS endpoint and validate the signature, issuer and audience. Introspection is also available at POST /partner/v1/oauth/introspect for opaque validation.

The ring publishes its OAuth metadata at the standard /.well-known/oauth-authorization-server discovery document, so most OAuth libraries can configure themselves automatically from the base URL.