Skip to main content
You’re a bank, a microfinance institution, or a credit fintech. You have an underwriting model that works beautifully for borrowers with two years of bank statements. It falls apart on the people who need credit most — bricklayers, tailors, traders, anyone whose income arrives in cash on uneven days. The Partner API is your answer to that. When a Job Seeker or trader applies for credit through your product, they grant Guild consent to share their snapshot with you. We send you a signed JSON document containing their standing tier, their behavioural signals, and a configurable window of their audit ledger. You feed it into your underwriting model. You decide. You disburse over OPay payout. Repayments run by direct debit on the schedule your borrower accepted, written to the same ledger. Every layer of this is verifiable.

Four things you get

Consent-gated reads

Every snapshot fetch requires an active consent record. The user explicitly grants you access, scoped to your API key and revocable at any time. We never share data you weren’t granted access to.

Signed snapshots

Each snapshot is signed with our Ed25519 key. You verify against our public key. The signature covers the user ID, the standing tier, the score, the signals, the audit-ledger window, and the timestamp. Tamper detection is automatic.

Real-time webhooks

Subscribe to consent.granted, consent.revoked, and standing.tier_changed events. You get push notifications when your borrower’s situation changes — not a daily polling job.

Predictable rate limits

100 read calls per second per API key. Bursts up to 200 for 5 seconds. Webhooks are unlimited inbound. Above that, talk to us — we’ll provision dedicated capacity.

What’s actually in a snapshot

The signature covers everything above. If a single byte of this payload is altered after we sent it, signature verification fails on your side. Detailed field semantics in Snapshots.

How a typical integration works

1

Get your API key

From partners.guild.com.ng/keys. One key per environment (sandbox + production). See API keys.
2

Ask the user for consent

Either from inside their Guild dashboard (we surface a consent prompt) or by sending them a consent link from your own product. Either way, we write the consent record on our side. See Consent.
3

Fetch the snapshot

GET /partner/v1/users/:userId/snapshot. You get the signed JSON above. Verify the signature against our public key (rotated quarterly with a 30-day overlap window). See Snapshots.
4

Make your underwriting decision

Your model. Your call.
5

Disburse over OPay payout

POST /partner/v1/disbursements. We coordinate the OPay payout to the user’s wallet or directly to their bank.
6

Repayments run by direct debit

On the schedule the user accepted at disbursement. Each repayment writes to both their Guild ledger and your books.
7

Webhooks keep you in sync

Consent revocations, standing tier changes, repayment outcomes — all push events.

Sandbox vs production

Two parallel environments.
The live sandbox isn’t active yet. We’re finalising the synthetic-user dataset and the sandbox webhook delivery infrastructure. If you’re integrating now, talk to us and we’ll arrange a sandbox handshake when it’s ready. The endpoints and shapes documented here are the spec we’re shipping against.
Sandbox responses are signed with a sandbox key (different public key, marked sandbox in the JWK). Production responses are signed with our production key. Don’t accept a sandbox signature on a production transaction — your verifier should pin the key environment.

What lending products work well on Guild data

Two patterns we’ve seen partners succeed with: Inventory advance for traders. Eligibility threshold tied to monthly velocity (≥₦80k daily average, ≥30 distinct customers, Trusted tier). Loan size 30-50% of monthly velocity. Term 8-16 weeks. Repaid by weekly direct debit from the trader’s wallet. Default rate has trended well below the bank’s other unsecured products on file. Tool-equipment loans for skilled workers. Eligibility threshold tied to completed jobs (≥30 over 60 days, Trusted tier, average review ≥4.0). Loan size 50-100% of trailing-30-day earnings. Term 4-12 weeks. Repaid by weekly direct debit triggered after each OPay payout lands in their wallet. Both depend on Guild’s data being verifiable and on the borrower’s incentive to maintain their standing (the loop: bad behaviour → lower standing → fewer offers).

What’s not in scope at v1

We don’t surface raw transaction-level data to partners. The ledger window in a snapshot is aggregated — totals, counts, counterparty counts — not transaction-by-transaction details. This is a privacy choice; it protects the user’s specific employer relationships and customer identities while still giving you the underwriting signal you need. If your model needs transaction-level granularity, we can discuss a higher-trust tier with stricter consent and audit requirements. Talk to us.

Pricing

Free for the snapshot reads, the consent flow, the webhook subscriptions, and the API key management. Per-disbursement: a small percentage of the loan principal, settled at disbursement. This is how Guild makes money on this side — we’re aligned with the partner on volume, not on individual transactions. Per-repayment: zero. Direct debit through OPay has its own per-transaction cost which OPay absorbs in their merchant agreement with us. Details in your contract; the pricing surface is intentionally simple.

Next

API keys

How to get a key and how authentication works.

Consent

The granular permission model and how to drive the consent flow.