Overview

NextLevel MCA is a deal platform for merchant cash advance brokers. The public API exposes the objects and rules the app uses, at https://api.nextlevelmca.com/v1, so anything you build on it behaves like a team member working in the app: the same permission checks, the same stage rules, the same field masking. Three surfaces share one contract:

• REST API at https://api.nextlevelmca.com/v1, authenticated with an API key or an OAuth token.
• Webhooks that push events (a deal was created, an offer came in, a statement was analysed) to your endpoint.
• MCP server at https://api.nextlevelmca.com/mcp, so Claude, ChatGPT and other MCP clients can read and act on your pipeline after a user signs in.

​

Object model

​

Businesses

A business is the merchant: legal name, DBA, EIN, industry, state and contact details. Every deal belongs to one business, and a business accumulates deals and advances over time. Creating a business runs duplicate detection on EIN and on normalised name plus state; a match returns 409 with code: "duplicate_business" and the existing_id, unless you pass ?force=true. Businesses carry their own notes, tasks and activity timeline.

​

People

People are the owners and contacts behind a business, linked with a role and an ownership percentage. A person can be attached to more than one business. GET /v1/people?phone= normalises the number to E.164 before matching, which makes it the lookup for unknown inbound calls and texts. Sensitive fields are protected: ssn is accepted on write and never returned (reads show ssn_masked, for example ***-**-6789), and dob is only returned to admin and manager credentials.

​

Deals

A deal is one funding request for a business. It holds the requested amount, the application data (form_data), a paper grade, documents, notes and tasks, and it sits in exactly one pipeline stage. Stages are grouped into phases (preoffer, offer, contract, funded, dead). Some stages are bound to events: with the default board, Submitted is entered automatically on the first submission and Funded on mark_funded, and those stages cannot be entered by hand. GET /v1/pipeline returns the stages, phases and bindings for your location. Renewals are deals too, created from a funded advance with POST /v1/deals/{id}/renewal and linked back through renewal_of_deal_id.

​

Submissions

A submission is a deal sent to one lender. POST /v1/deals/{id}/submissions records one submission per lender and, when send is true and the location has a connected mailbox, queues the same email the app would send. The create response reports each queued submission as queued (or recorded when there is no mailbox); on later reads it is pending until the email goes out, then sent, and lender replies move it to approved, declined or needs_info. Submissions can be withdrawn unless they are approved or funded.

​

Offers

An offer is a lender’s terms for a deal: amount, factor rate, term, payment frequency and points. Offers are logged with POST /v1/deals/{id}/offers or by your team in the app; the first offer moves the deal into the offer phase. One offer is primary: setting it with POST /v1/offers/{id}/primary syncs the deal status to that offer, and from then on the offer’s status changes (contracts requested, sent, signed) move the deal stage through the location’s event bindings.

​

Advances

Marking a deal funded creates an advance: the funded amount, the payback, what has been paid so far (paid_amount, percent_paid) and whether it is renewal-ready. renewal_ready becomes true once percent_paid reaches the location’s renewal threshold (50% by default, overridable per advance), and GET /v1/advances?renewal_ready=true is the list an agent works from to start renewals.

​

Locations

Every object above belongs to exactly one location: a workspace in the app, usually one brokerage or team. Credentials are issued per location. An API key created in a location, or an OAuth token approved for a location, can only read and write that location’s data; a record from another location is a 404. There are no cross-location credentials in v1. To integrate two locations, create a key in each.

​

Next steps