Lunch Partner API
Your vendors get paid when their invoice is financed instead of when it is due. You keep the relationship; Lunch carries the money and the risk.
The whole integration is four calls:
| Sync a business | PUT /v1/organizations/{externalId} — with your own identifier for it |
| Sync an invoice | PUT /v1/invoices/{externalId} — payee, payor, face value, dates |
| Quote | POST /v1/quotes — what a face value would cost, naming no invoice |
| Advance | POST /v1/advances — take it against a synced invoice |
Everything is keyed on your identifiers. You never store a Lunch id, and each of these writes is idempotent on the identifier you send, so replaying your ledger updates rather than duplicates. (Subscribing to a webhook destination is the one exception.)
Before a business can borrow
Three gates, independent of each other, all reported by
GET /v1/organizations/{externalId}:
- Compliance — we hold a tax identification number and it has cleared.
- An agreement — somebody at the business has signed it.
- A bank account — we know where the money goes.
Today, get a business through them by inviting it: set the payout account yourself with
PUT /v1/organizations/{externalId}/payout-account
when you already hold the vendor's bank details, and send them
POST /v1/invitations to claim the account and sign.
Hosted onboarding is published but not yet live
POST /v1/onboarding-sessions mints a single-use link
that collects all three gates over your own page, without the vendor leaving your product. Its
shape is published so an integration can be written against it now — a link minted today
resolves to nothing. We will tell you when it is serving.
Where to go next
- Authentication — your key, and what the playground on this site does with it
- Financing an invoice — the four calls end to end
- Webhooks — events, signatures, and verifying one
- Errors — the shape every failure takes, and the codes to branch on
- API reference — every operation, generated from the contract itself