Karibu ID with Coupa — an integration recipe

A guide, not code, built only from Karibu ID's published contract (contracts/openapi.json, v0.57.0): the reader API, the reader webhooks and the exports (FA v5.7 §36.7). It describes one way a buyer can use Karibu ID records in Coupa supplier management. Karibu ID has no partnership with Coupa; Coupa is a trademark of its owner. Karibu ID reports findings, never verdicts: the supplier decision stays the buyer's.

What you need

• A reader organisation in Karibu ID with exports on, and a reader admin.
• A small service between the two that receives HTTPS POSTs, calls Karibu ID's API and Coupa's, and keeps the webhook signing secret and the access token in a secret store.

1. Link suppliers

1. Invite the suppliers you need by CSV (POST /v1/reader/invitations/imports) or one at a time (POST /v1/reader/invitations).
2. On share_granted (a webhook; verify KaribuID-Signature first), store the company's KE on the Coupa supplier record.

2. A scheduled view

Once a day, import the portfolio and its expiries:

• GET /v1/reader/exports/portfolio?format=csv: each company that shares with you, its tier under your own rules, its status and whether a decision is due;
• GET /v1/reader/exports/expiries?format=csv: shares, invitations, requests and review dates ending in 30, 60 and 90 days.

Text cells that would read as a formula are prefixed with a quote, so a spreadsheet never runs them. Follow X-Karibu-Next-Cursor for the next page.

3. Changes

Route the webhook events to supplier tasks in Coupa:

• ledger_high, ledger_medium: a status change on the company register (struck off, in liquidation, a licence suspended); the high ones always reach you;
• finding_new, report_superseded: a new version of the record to review;
• reader_decision_due: your own review is due under your rules.

Every body carries ids only; fetch the detail signed in.

4. Single sign-on

Your staff can sign in to Karibu ID through your own identity provider: a reader admin records the provider (OIDC or SAML), your email domains and which of your groups map to which Karibu ID reader role (PUT /v1/reader/sso, with a recent passkey). A group you do not map grants nothing, and sensitive actions still ask for a passkey.