Recipe

Submit an application on partner/v1

Take an application end to end on the partner ring: mint a token, POST /applications with an idempotency key, then read the decision. Retry safely and never double-submit.

2 min read

OAuthToken first

IdempotencyOn the POST

DecisionRead after

1. Mint a scoped token

Get a token scoped to what you need (see client credentials):

TOKEN=$(curl -s -X POST https://hub.credicorp.co.uk/partner/v1/oauth/token \
  -d grant_type=client_credentials -d client_id=$ID -d client_secret=$SECRET \
  -d scope='applications:write decisions:read' | jq -r .access_token)

2. Submit with an idempotency key

curl -s -X POST https://hub.credicorp.co.uk/partner/v1/applications \
  -H 'Authorization: Bearer '$TOKEN \
  -H 'Idempotency-Key: '$(uuidgen) \
  -H 'Content-Type: application/json' -d @application.json

The idempotency key means a timed-out retry returns the original result instead of opening a second case. Mind the 5 req/s sub-limit on POST /applications.

3. Read the decision

Poll GET /decisions/{id} or, better, subscribe to a webhook for the decision event so you are pushed the result instead of polling. Handle errors by family: re-mint on an expired token, back off on 429/5xx, never retry a 422. Money-out remains a governed manual gate.

Frequently asked questions

How do I avoid submitting the same application twice?

Send an Idempotency-Key header on POST /applications, derived from your own record ID or a UUID stored with the job. A retry with the same key returns the original result instead of opening a second decisioning case.

Should I poll for the decision or use a webhook?

Prefer a webhook — you are pushed the decision event instead of burning rate limit polling. Poll only as a fallback, and back off between polls to respect the bucket.