One Core. Three ways to adopt.
Run the whole loan-origination system under your brand, or build your own front-end on the API and let the Core run the regulated engine underneath. One Core powers both what you run and what your partners connect to, so you decide who renders each step: you, OneApp Finance, or a partner you bring in.
Pick your altitude
OneApp Finance is one headless Core, the single brain and system of record. You run it for your own program at the height that fits your build. The rule under all three: the Core owns every state, every decision, and every piece of evidence. Any screen, ours or yours, is a thin client that shows what the Core says and sends back what the borrower did. Altitude is a separate choice from your operating model: direct, multi-lender, or hybrid is what you run; run, embed, or route is how much of the stack you adopt.
RUN
Take the whole stack: the Core, our white-label borrower and contractor screens, and the operations portal. Everything the homeowner and the salesperson touch wears your brand. This is the flagship setup.
EMBED
Build your own borrower and contractor experience on the API, and let the OneApp Finance Core run the regulated engine underneath. You choose which steps your app renders and which OneApp Finance runs, all inside one application.
ROUTE
Run intake, eligibility, and one soft pull, then fan the application out to your panel of partner lenders, gather their offers, and let the borrower pick. Multi-lender routing, in parallel or as a waterfall, the mirror image of an inbound partner.
Own some steps. Let OneApp Finance run the rest. Same application.
Modularity isn't all-or-nothing per integration. It's per step. Every step in the loan, from intake and identity to the offer screen, e-sign, and funding, carries an ownership mode, and you set it in both directions: which steps your own experience renders, and which steps a connected partner is allowed to run. Everything else goes to the OneApp Finance Core, and it all lives in one application with one record of truth.
- OneApp Finance-hosted. We render the white-label step on the borrower's device or inside an iframe in your page. Your brand, our screen, our logic.
- API-integrated. Your own UI renders the step and calls the Core directly. Your pixels, OneApp Finance's logic and evidence behind them.
- Partner-delegated. You run the whole step in your UX and report the result back, but only with a full evidence package, never a bare yes/no. Delegated steps are adversarial until your environment is certified.
- Mix all three in one application. A single application can run a OneApp Finance-hosted identity check, your own offer screen, and a delegated e-sign, together, in order, with the Core stitching it into one auditable trail.
Every step is a unit
- Intake, captured by you or by us
- Identity, verified on the borrower's own device
- Decision, run against your model, headless if you like
- Offer, our offer screen or your own
- E-sign, hosted, embedded, or delegated with evidence
- Funding, staged draws the homeowner confirms
No code, a little code, or full control
This is how a channel plugs into your program, whether it's your own team or a contractor network, retailer, or platform you bring in. Every method drives the same Core through the same API, with no private backdoors. You decide which one each partner uses, and which steps they're allowed to run.
Hosted page
Send a link, show a QR code, or text-to-apply. The homeowner finishes on their own phone, on a page we host under your brand. Zero engineering on your side. Because the link goes to the borrower's device, the salesperson can't drive the consent screen.
Embedded
Drop a snippet into your CRM or proposal tool. Our SDK or iframe mounts the flow, the whole sequence or a single step, inside your page. Sensitive fields render in our iframe, so borrower PII never touches your page.
Full API
Run your own experience end to end and integrate against the REST API directly. Send an application, get a decision, fund the loan. No OneApp Finance screens at all, except the one step we always re-perform ourselves (see below).
Your brand, set by tokens. No code.
White-label here means brand skin plus content config, full stop. You set a small, named set of brand tokens and the entire borrower experience resolves to your brand. You're editing named values, not stylesheets, so it stays safe to expose and impossible to break the accessible, tested design underneath.
- Color, logo, font. A handful of color inputs, your logos, and a font from a curated allowlist. The system computes the rest of the palette for you.
- Custom domain. Run the hosted apply page on your own domain. We verify it before any live link uses it.
- Your sender identity. Texts and emails go out from your verified sender, not ours. We won't send a one-time code from an unverified domain.
- Light and dark, accessible by default. Status colors are clamped, so a theme can't make a decline look like an approval, and contrast is checked at build time. A borrower must be able to read a decline as a decline.
What you set
- Brand color, logo, and an allowlisted font
- Your own custom domain, verified first
- A verified sender for texts and emails
- Light and dark themes, contrast-gated
Compliance gates are always re-enforced by the Core
Borrower authorization is non-delegable
Even on a fully headless channel, when the flow reaches authorization, OneApp Finance is built to re-run the consent step on the homeowner's own device. The partner never owns that screen.
Identity and sanctions, every time
Identity verification and sanctions screening are gates the Core is designed to perform itself. A sanctions block is a hard stop; it is never auto-resolved.
Evidence, not booleans
A delegated step is accepted only with a structured evidence package: the signed artifact, a hash of the exact screen the borrower saw, device and session data, and replay protection. There is no "consent: true" shortcut anywhere in the API.
Money safety can't be configured off
Disbursement preconditions, disclosure versioning, and adverse-action timing are designed as invariants, structural, not a setting. Try to approve funding without a consent artifact and the API is built to return a non-retryable, non-overridable error.
Building the integration?
The endpoints, OAuth, idempotency, the event catalog, and signed webhooks live on the Developers page. See the API reference →
Common questions
Can I own some steps and let OneApp Finance run the others in the same application?
If I go fully headless, does any OneApp Finance screen ever show?
How does white-label work without code?
Is OneApp Finance the lender?
Does moving between modes mean re-integrating?
Adopt it your way
Run it, embed it, or go headless, and let the Core keep the floor either way. Let's map your steps.