Skip to main content
This is the walkthrough for whoever builds the integration. It takes a deal from nothing to offers in five requests, the same path a rep follows in the app. You need an API key (see Access and permissions) with businesses:write, deals:write, lenders:read, submissions:write and offers:read, or one with no scope restriction.
Request bodies carry only the fields the flow needs, and responses are cut down to the fields that matter here. Every field, filter and response property is on the endpoint’s page in the API reference tab.
1

Create the merchant

A business is the merchant. Create it once; every deal for this merchant hangs off it.
Response 201
If a business with the same EIN, or the same legal name in the same state, already exists you get 409 with code: "duplicate_business" and existing_id. Use that id, or repeat the call with ?force=true to create a second record anyway.
2

Open a deal

A deal is one funding request. It lands in the first stage of the pipeline, exactly as if a rep had created it.
Response 201
A deal.created notification fires. You can also create the business inline by sending a business object instead of business_id (duplicate detection applies the same way), and an owner object creates the primary owner or links an existing person matched by email or phone.
3

See which lenders fit, and why

Matching runs the workspace’s lender criteria against the deal and explains every check. If you have bank statements, upload them first (see Documents and bank statements): once they are analysed, matching uses bank-verified revenue instead of the stated figure.
Response 200
view=recommended is the shortlist an underwriter would send to. view=eligible also includes lenders that pass every hard gate but score lower; view=all adds disqualified lenders with their reasons. auto_eligible marks matches with nothing unknown, safe for an automated send, and meta.deal.missing_fields tells you what to collect to raise confidence.
4

Send it to two lenders

Submitting sends real email (or, for lenders with an API integration, a real application), so attach an Idempotency-Key: a retry with the same key replays the first answer instead of sending twice.
Response 201
One submission is recorded per lender, with the match score snapshotted. Each goes out in the background through the workspace’s connected mailbox: the status moves from queued through pending to sent, and a submission.sent notification fires per lender. Lenders that already had a submission on the deal are left alone and listed in meta.already_submitted. If the workspace has no connected mailbox, the submissions are still recorded (status: "recorded", meta.warning: "no_email_sender") for the team to send from the app. Pass "send": false to record without sending. The first submission also moves the deal to the Submitted stage on the default board.
5

Read the offers

Offers appear as lenders respond (an offer.received notification fires) or when someone logs them in the app.
Response 200
To pick one, call POST /v1/offers/{id}/primary. The deal’s status follows that offer from then on, and as the offer moves (contracts requested, sent, signed) the deal moves stage with it. Funding goes through POST /v1/deals/{id}/stage with event: "mark_funded", which creates the advance.

Where next

How the API behaves

Errors, paging, safe retries and the fair-use limit.

Notifications

Get told when offers arrive instead of asking.

AI workflows

Turn these five calls into an agent.