Integration Guide

Aggregator / Offtaker

This is a structural pattern, not one specific business: you sit between many upstream suppliers and a downstream ecosystem of buyers, and credit may flow in both directions — upstream to keep supply moving, downstream to move more volume. This guide maps that pattern onto the Embedded Finance API so you can see exactly which endpoints to build against, whatever your ecosystem actually deals in — and where we're honest that something isn't built yet.

Live works today, documented in the API referenceTargetthe intended design — not shippable yet, don't build a launch date around it without confirming

The pattern, in our terms

The platform's own taxonomy calls this the Aggregator / Offtakervalue chain role — any business that buys from many upstream suppliers and sells on to a downstream ecosystem. Here's how that structural pattern maps onto the API, independent of what actually moves through your ecosystem:

The pattern	Maps to	Status
You buy from many upstream suppliers	Partners API — register with `value_chain_role: aggregator_offtaker`	Live
You may extend credit upstream to keep suppliers producing for you	Supplier Credit (Network bundle) — the API docs' own worked example for this programme is “aggregator→supplier input credit”	Live
You sell on to a downstream ecosystem of buyers	Participants API — register each buyer as a network participant in your ecosystem	Live
Your buyers can pay on credit instead of upfront	Merchant Credit / Purchase-Inventory Financing (Network bundle) extended to the buyer	Live
You're paid immediately; MightyFin carries the buyer's repayment	“Closed-loop financing” — you're settled directly from the buyer's new credit line	Target
None of this looks like MightyFin to your suppliers or buyers	Partner branding — your name, logo, support contact on every participant-facing interaction	Live
Your suppliers and buyers use a portal on your own domain	Custom/subdomain hosting and partner-hosted KYC — today, identity verification redirects to a MightyFin-hosted URL	Target
What a supplier owes on input credit nets against what you owe them for goods delivered	No such mechanism exists — these are two separate flows today	Target

The shape of your integration

One partner account, two participant populations, one shared wallet and identity layer underneath both — regardless of what your suppliers produce or your buyers do with it.

Your Integration, End to End

Flow 1 — extending credit upstream

Every step below is live and documented in the API reference. The one open question is at the end: nothing here automatically nets a supplier's payment for delivered goods against their outstanding input credit — you'd run those as two separate settlements today.

Register the supplier via the Participants API. The docs' own example uses role_in_network: "retailer" — confirm the exact accepted values for a supplier role with your MightyFin contact before you hardcode one.
Start identity verification via the Identity & KYC API (individual_kyc for an individual, business_kyb if they're incorporated).
Submit a supplier_credit application via the Credit API on the supplier's behalf, or let them request it themselves through your portal.
Once approved, funds disburse to the supplier's wallet — they draw on it for inputs.
As they deliver goods, you pay them through Bulk Payouts or wallet transfers.
The supplier repays their Supplier Credit balance separately, through the Repayments API (wallet-first collection).

Target

Steps 5 and 6 are genuinely disconnected today. If a supplier's payment for delivered goods could auto-offset their outstanding input credit — pay them the net, not the gross — that removes a manual reconciliation step for you. It doesn't exist in the API or the internal roadmap yet; flag it as a product request if it matters for launch.

Flow 2 — extending credit downstream

This is the flow that makes the pitch land: your buyer draws credit, you get paid now, MightyFin collects from the buyer over time. The onboarding and credit-lifecycle mechanics are live; the instant-settlement mechanic is the one piece that's only a documented intention so far.

Downstream Buyer Credit — Intended Flow

Target

The “disbursed → funds settle to you” step is the load-bearing one, and it's the least documented part of the whole platform. The internal roadmap describes it as closed-loop financing: “a downstream buyer borrows specifically to pay an upstream partner, and MightyFin settles the partner directly from the buyer's new credit line.” That's a product intention, not a spec — there's no documented answer yet for which wallet receives the disbursement, or how confirming delivery (the planned Commerce Finance API) is meant to trigger it. Don't commit a go-live date on this mechanic without a real settlement design signed off first.

Credit limits are pooled beyond your ecosystem

A participant's credit limit is pooled across everything they're eligible for — not scoped to their relationship with you. If a supplier or buyer has any other active MightyFin relationship, its usage draws down the same limit theirs does with you.

Know this going in

This combines with something you already know: you only ever see your own relationship with a participant, never their activity elsewhere. Put together, a supplier or buyer can be declined or capped on credit with you for reasons entirely invisible to you — nothing about their standing in your ecosystem changed, their limit was just already spoken for somewhere you can't see. Worth knowing before you build any UX that assumes a decline must trace back to something that happened on your side.

White-labeling — what's live vs. what's roadmap

Live: your name, logo, and support contact appear on every participant-facing interaction, via the Partners API's branding endpoint.
Live today, but visibly MightyFin's: we need to vet a participant to decide on them — identity verification is a direct input into the credit decision, not a separate control step. Today that vetting has to happen on our domain: it redirects to a MightyFin-hosted URL, briefly leaving your brand.
Target: a custom domain or subdomain for your own portal, and a partner-hosted or embeddable KYC flow. Both are named as intended in the internal roadmap with no design committed yet.

Who does what — and why it helps you

MightyFin's job is to carry the parts of this that require a license, a balance sheet, and a compliance function — underwriting, custody, regulatory reporting — so you don't have to become a regulated lender to offer credit inside your own ecosystem. Your job is the part your suppliers and buyers actually see and value: the brand, the relationship, the goods, the deals. We don't own how you run either side of that — the one thing we need directly is enough to know who a participant is, because identity and verification status feed straight into the decision itself. That's the extent of it: vetting in service of a decision, not a claim on how your business operates.

Practically, that means credit decisions come back to you as an outcome — approved, declined with a reason code, eligible alternatives — without you needing to build or maintain risk models yourself. Your relationship with each participant is yours: private to you, shaped entirely by how you choose to work with them. And a supplier or buyer doesn't start from zero the second time they show up anywhere in the network — their credit standing carries over, which is part of why onboarding gets faster the more the network grows.

Open items to confirm before go-live

These are the pieces that outrun what's documented as built. Raise them explicitly rather than assuming they'll be ready:

Exact settlement mechanics for the downstream buyer-funded purchase — whose wallet, at what point in the flow.
Supplier payment-for-goods vs. input-credit netting — currently two unconnected flows.
Custom domain / partner-hosted KYC timeline, if a fully white-labeled portal is a launch requirement.
Uptime/SLA commitments — no committed numbers exist yet for partner-facing endpoints.
Today's OAuth2 client-credentials setup works, but it's a stopgap — the documented direction is org-scoped OIDC. Don't hard-code assumptions about token shape or scope format that might change later.
The API reference states that every participant is automatically screened against sanctions and PEP lists as part of verification. Confirm this is actually live with your MightyFin contact before relying on it for your own compliance posture — treat it as unconfirmed rather than guaranteed until you hear otherwise.