Getting loan pipeline data out of BrightBridge CU MyMortgage

Strip away the branding and this is a tenant of the SimpleNexus homeownership platform, the white-label borrower and loan-officer app that nCino now ships as its Mortgage Suite. The package on the Play listing is com.simplenexus.loans.client; BrightBridge's build carries the instance suffix s__49778, which is how SimpleNexus separates one lender's deployment from the next. That single fact decides most of the integration: the data you want is not invented per credit union, it sits in a documented platform behind a per-tenant configuration.

For a team that wants BrightBridge loan activity flowing into a CRM, a servicing core, or a data warehouse, the practical shape is a batch backfill of the existing pipeline followed by webhook events keeping it current. We build that connector, ship the source, and hand over the docs. The rest of this page maps what is reachable and how we'd wire it.

Loan data inside the app

The app describes itself as a way to apply, scan and upload documents, compare loan programs, reach a loan officer, and run refinance and affordability math. Each of those maps to a server-side record. The math screens are local calculators and hold nothing worth syncing; the rest is pipeline data.

Authorized routes

Three routes apply here. They are not equal, and we tell you which we'd take.

1 — Authorized platform API and webhooks

SimpleNexus publishes a developer surface (the legacy SNAPI and the newer nCino Mortgage API at developer.ncinomortgage.com) plus a webhook flow with event filtering and delivery retries. Authentication and payloads differ between the two API generations, which we handle in the client we write. This is the durable route: reachable data is broad, the contract is documented, and events keep the copy fresh. We arrange the tenant access with BrightBridge during onboarding so the connector runs against the real instance.

2 — Protocol analysis of the app's traffic

Where a needed field is not exposed through the API tier the lender has enabled, we map the app's own authenticated calls under BrightBridge's authorization and implement against the observed request and response shapes. More maintenance than the API route, but it reaches anything the app itself can see.

3 — Native export hand-off

For one-off migrations, document and loan exports the platform already produces can be normalized rather than polled live. Lowest effort, no live freshness — a fit for backfills, not steady-state sync.

We'd run route 1 as the backbone and keep route 2 in reserve for the handful of fields a given tenant doesn't surface through the API. Route 3 covers the initial history load if a bulk export is cleaner than paging the whole pipeline.

Worked example: a milestone event and a backfill page

An illustrative webhook payload for a status change, and the cursor pull we pair with it. Field names follow the platform's documented shapes and are confirmed against the live tenant during the build.

# 1) Live edge — milestone webhook (verify signature, then enqueue)
POST /hooks/brightbridge/loan-events
{
  "event": "loan.milestone.changed",
  "loan_id": "BB-49778-0007421",
  "from": "processing",
  "to": "conditional_approval",
  "occurred_at": "2026-06-05T15:02:11Z",
  "loan_officer_id": "lo_3391"
}

# 2) History — cursor batch backfill across the pipeline
GET /v0/loans?updated_since=2026-01-01&cursor=eyJwYWdlIjozfQ
Authorization: Bearer <tenant_token>
-> 200 {
     "loans": [ { "loan_id": "...", "status": "...", "documents": [...] } ],
     "next_cursor": "eyJwYWdlIjo0fQ",
     "has_more": true
   }

# reconcile: webhook events override backfill rows by occurred_at,
# so a replayed page never regresses a newer status.

How a normalized loan record looks

We flatten the per-tenant shapes into one record your systems can rely on, regardless of which route fed it.

{
  "loan_id": "BB-49778-0007421",
  "borrower": { "name": "...", "email": "..." },
  "property": { "address": "...", "purpose": "refinance" },
  "program": "30yr_fixed_conventional",
  "status": "conditional_approval",
  "milestones": [ { "name": "submitted", "at": "..." } ],
  "documents": [ { "type": "paystub", "uri": "...", "scanned": true } ],
  "loan_officer": { "id": "lo_3391", "name": "..." },
  "source_route": "api|protocol|export",
  "synced_at": "2026-06-07T00:00:00Z"
}

What lands in your repo

• Runnable connector source in Python or Node.js — the milestone webhook handler, the cursor backfill loop, and the normalizer above, ready to run against the BrightBridge tenant.
• A signed-webhook receiver with signature verification and a small replay buffer, so a redelivered event is safe to process.
• An automated test harness covering the status-transition logic and the backfill reconciliation, with recorded fixtures so a contract change shows up as a failing assertion.
• Batch-vs-realtime sync design: where the line sits between the one-time pipeline load and the steady webhook feed for this lender's volume.
• An OpenAPI/auth-flow spec documenting the token model for whichever API generation the tenant runs.
• Interface documentation and data-retention notes for the loan and document records you take in.

What we plan around in this build

Two things specific to a SimpleNexus tenant shape the work, and we account for both rather than handing you a list to satisfy first.

Per-tenant configuration. The s__49778 instance has its own milestone names, enabled loan programs and document requirements. We map BrightBridge's actual configuration so the connector emits this credit union's status set, not a generic one, and so a renamed milestone doesn't silently drop events.

Two API generations. Auth and payloads diverge between the legacy SNAPI and the nCino Mortgage API. We confirm which generation BrightBridge's tenant is on and write the token handling for it, keeping the normalizer stable so a later platform migration doesn't ripple into your systems. Access to the tenant or a consenting test loan is arranged with BrightBridge during onboarding.

Consent and data-rights footing

This is member loan data, so the build runs on authorized, logged, data-minimized access with NDAs where the lender wants them. The dependable legal basis is the member's own consent to move their file — that is what we design to. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is the forward-looking piece, not current law: a federal court enjoined enforcement, the rule is back in agency reconsideration, and the compliance dates that were set have been paused. We don't ride it as settled footing; we shape the consent records and schema so that if an open-banking rule lands, adopting it is a configuration change rather than a rebuild.

Inside the app

How this was put together

I worked from BrightBridge's Play Store listing and feature copy, the SimpleNexus / nCino platform and developer material describing its API, webhooks and LOS integrations, and the current US regulatory record on Section 1033. The package suffix and platform lineage were checked against the public listing; the §1033 status against primary regulatory and legal sources. Citations:

• SimpleNexus / nCino — API and webhooks overview
• nCino Mortgage developer portal — SNAPI getting started
• Google Play — SimpleNexus Mortgage App listing
• CFPB — Personal Financial Data Rights (status)

OpenFinance Lab · integration assessment, June 2026.

Other mortgage apps in the same integration space

Same category, similar data, all candidates for one unified loan-data layer:

• Blend — borrower-facing POS used by many banks and credit unions; holds application and document data.
• Floify — loan-officer portal with document collection and status tracking.
• BeSmartee — point-of-sale application flow with automated underwriting hooks.
• Maxwell — digital mortgage platform aimed at credit unions and community lenders.
• Roostify (CoreLogic) — application and document workflow for lenders.
• Cloudvirga — POS focused on the borrower intake and pricing experience.
• MortgageHippo — white-label borrower journey with status and document upload.
• BNTouch — mortgage CRM and POS combining lead and loan data.

Questions integrators ask about this app

Does loan data arrive as a webhook push or a batch pull?

Both, and we usually run them together. The SimpleNexus platform behind this app emits webhook events on milestone and resource changes with delivery retries, which we treat as the live edge. For history and for any window where a webhook was missed, the connector does a cursor-based batch backfill across the loan pipeline so the local copy reconciles to a known state.

Which loan fields and documents can the connector actually see?

The application record (borrower, co-borrower, property, loan program and scenario inputs), milestone and status transitions, the uploaded document set the app captures through its scanner, pre-approval letters, and loan-officer assignment. Field availability depends on the lender's instance configuration, which we confirm against the live tenant during the build.

Where does this sit with US data-rights rules?

The dependable basis is the member's own authorization to move their loan data. The CFPB Personal Financial Data Rights rule under 12 CFR Part 1033 is not in force; a federal court enjoined enforcement and the rule is back in agency reconsideration, with the earlier compliance dates paused. We build to consent today and design the schema so a future open-banking rule can be adopted without a rewrite.

The package ID ends in s__49778 — does that change the integration?

That suffix marks BrightBridge's own white-label instance of the shared SimpleNexus client, per the Play Store package naming. It does not change the method; it tells us which tenant and configuration the connector targets, so milestone names, enabled loan programs and document requirements match this credit union rather than the generic build.

A first working build of the BrightBridge CU MyMortgage connector lands in one to two weeks. Source-code delivery starts at $300 — runnable connector plus docs, and you pay after delivery once it works for you; if you'd rather not host anything, our pay-per-call hosted API has no upfront fee and bills only for the calls you make. Send the app name and what you want from its data and we'll scope it — Start a BrightBridge integration