Pulling loan status and document events out of the Southwest Funding app

Open the Southwest Funding app's package id — com.simplenexus.loans.client.s__117433, per its Google Play listing — and the backend names itself. This is a lender-branded build of SimpleNexus, the digital mortgage platform now folded into nCino's Mortgage Suite. That single fact decides the whole integration. The data a borrower sees in the SWF app does not live in a separate Southwest Funding server; it lives in a shared platform that already moves loan events around over webhooks and a REST surface. So the question is not how to reverse a one-off mobile backend. It is how to subscribe, under Southwest Funding's authorization, to the slice of that platform that belongs to this lender's tenant.

Southwest Funding, a Dallas mortgage lender operating since 1993 per its own description, writes Conventional, FHA, VA, USDA, and refinance loans across the United States. The app's job is the borrower side of that pipeline: apply, scan documents, watch the file move, and reach the loan officer. Each of those is a data surface, and the event-driven shape of the platform underneath is what makes a near-real-time integration practical rather than a polling chore.

The route we would take: subscribe to the platform's webhook events for the Southwest Funding tenant, enrich each event with a REST read, normalize the result, and hand you runnable source plus the schema. Where a lender wants no onboarding at all, a borrower-consented path against the app's own authenticated traffic reaches the same records. Both are below.

What the SWF app stores

The app's own feature list, read against how SimpleNexus documents the borrower experience, maps cleanly onto distinct data domains. Each one originates somewhere specific and carries a different granularity.

Routes to the loan data

Three routes genuinely apply here. They differ in what they reach, how much setup sits on the lender side, and how long they hold up.

1. Tenant-scoped platform integration (recommended)

Subscribe to the platform's webhook events for Southwest Funding's instance and read the matching records over its REST surface. Reachable: loan status, document and condition state, application data, org and user changes — the full borrower file as the lender holds it. Effort is moderate and front-loaded into wiring the event handler and the normalizer. Durability is high, because this rides the same interfaces the lender's own back-office tooling uses; it does not break when the app's UI changes. We arrange tenant credentials and webhook subscriptions with you during onboarding and run the build against a tenant sandbox or a consenting account. This is the route we recommend for any lender that owns or can authorize its instance.

2. Borrower-consented session access

When a borrower authorizes us, we analyze the app's own authenticated traffic and replay the calls that fetch their file — status, documents, contacts. Reachable: everything a single borrower can see in the app. Effort is low per borrower; durability is medium, since it follows the mobile client and re-validates when the client updates. This path needs no lender onboarding, which makes it the fit for aggregation across lenders or for a borrower-side product.

3. Native export fallback

Where the app or its web portal lets a borrower pull a document set or a status summary, that export is the floor — always available, lowest fidelity, no live events. We use it to seed history or as a backstop when neither route above is in scope yet.

For most engagements route 1 carries the integration and route 2 fills the gaps it cannot, such as a borrower whose lender is not the one paying for the build. We say which fits in the first call, not after the invoice.

Source and specs we hand over

The deliverable is code you can run against your own loan data on day one, not a slide deck. For Southwest Funding that means, in this order:

• A runnable webhook service (Python or Node.js) that verifies signatures, dedupes deliveries, switches on milestone and document events, and enriches each with a REST read — the heart of the integration.
• A typed client / SDK for the loan, document, and company endpoints, with the cursor pagination the platform returns already handled.
• A normalized schema that flattens platform payloads into stable loan, document, and party objects, so your downstream code does not chase payload changes.
• An automated test suite — replayable event fixtures and contract tests against the endpoints, so a payload drift shows up before it reaches your pipeline.
• The OpenAPI / Swagger spec for the surface we touch, and a protocol & auth-flow write-up covering the token and signature chain as it actually behaves for this tenant.
• Interface documentation and data-retention guidance tuned to GLBA-covered nonpublic information.

The spec and the auth write-up matter, but they ship behind the code — the point is a service that runs, with the paperwork explaining it.

A webhook handler, end to end

Here is the spine of route 1 against a real surface of this app: a receiver for Southwest Funding loan events, signature-checked, with an enrichment read and the cursor pagination the platform uses for collection endpoints like /companies. Event names and the signature header are illustrative below; the exact keys are confirmed against the tenant during the build.

# Receiver for Southwest Funding loan events on the SimpleNexus / nCino surface.
import hmac, hashlib
from flask import Flask, request, abort
import requests

app = Flask(__name__)
SHARED_SECRET = b"..."                       # issued for the Southwest Funding tenant
API = "https://api.example-ncino.com"        # base URL confirmed at onboarding
seen = set()                                 # event ids already handled

def verify(req):
    sig = req.headers.get("X-Webhook-Signature", "")
    mac = hmac.new(SHARED_SECRET, req.get_data(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(sig, mac)

@app.post("/webhooks/swf")
def on_event():
    if not verify(request):
        abort(401)
    e = request.get_json()
    if e["id"] in seen:                      # delivery retries are expected; ignore repeats
        return "", 200
    seen.add(e["id"])

    if e["type"] == "loan.milestone.updated":
        loan = e["data"]["loan_id"]
        r = requests.get(f"{API}/loans/{loan}", headers=auth(), timeout=15)
        r.raise_for_status()
        push_to_crm(normalize(r.json()))     # flatten to the shared loan object
    elif e["type"] == "document.uploaded":
        sync_condition(e["data"]["loan_id"], e["data"]["document_id"])
    return "", 200

def companies():
    # follow the _links.next cursor the API returns on collection endpoints
    url = f"{API}/companies"
    while url:
        page = requests.get(url, headers=auth(), timeout=15).json()
        yield from page["data"]
        url = page.get("_links", {}).get("next")

The shape is deliberate. Events carry just enough to route; the REST read carries the detail. A failed signature is rejected, not logged-and-ignored. Pagination follows the cursor the API hands back rather than guessing page numbers.

Three jobs this enables

1. Live status mirror. Subscribe to milestone events, normalize them, and push to your own portal or CRM so a borrower (or a referring agent) sees movement without opening the app.
2. Conditions sync. On document events, update your underwriting conditions tracker and notify the assigned loan officer the moment a needed file arrives.
3. Lead and scenario capture. Pull application fields and calculator inputs into a marketing system for timed follow-up, with the transient calculator data treated as signal, not record.

Consent and the US data-rights picture

This is a mortgage borrower's file, so the operative privacy regime is the Gramm-Leach-Bliley Act and its handling rules for nonpublic personal information, not a generic data law. The dependable legal footing for reaching the data is plain: the borrower's own authorization, or the lender's authorization over loans it originates. We work from that — consent recorded, scope limited to the loans in play, data minimized to what the use case needs, and an NDA where the engagement calls for one.

The federal open-banking angle for this kind of data is unsettled, and we are honest about it on purpose. The CFPB's Personal Financial Data Rights rule under Section 1033 — the rule that could one day put a borrower's financial records on a mandated access footing — was enjoined in late 2025 and sent back into agency reconsideration. We do not design the Southwest Funding integration as though that rule governs today, because it does not. It is the direction the rules may move, not the basis we build on. Authorization is.

Engineering details we plan around

Two specifics about this app shape the build, and we handle both rather than hand them to you as homework.

• Two API generations under one roof. The platform carries an older SimpleNexus API (SNAPI) and a newer nCino Mortgage API whose authentication and payloads differ, per the developer docs. We target the newer surface wherever it covers what you need and fall back to the legacy one only where it does not, so the integration does not need re-platforming the next time the older surface is retired.
• One tenant on a shared platform. The package suffix s__117433 marks Southwest Funding as a single instance among many lenders on the same backend. We scope credentials and event subscriptions to this tenant so another lender's loans never bleed into the feed — a correctness issue, not a nicety, when the platform serves thousands of institutions.
• Documents live in the LOS. Because scanned files are written to the loan origination system and not retained on the device, the document route reads receipt and condition state from the LOS-backed store rather than caching raw files, and retention is designed around GLBA-covered information from the start.

Access — tenant credentials, a sandbox, or a consenting borrower account — is arranged with you during onboarding. It is part of how the project runs, not a gate you clear before we start.

Cost and how we work

Source delivery starts at $300, and you pay only after the code is in your hands and runs against your loan data — if it does not do what this brief describes, you owe nothing. That buys the webhook service, the client, the normalized schema, the tests, the spec, and the docs for the surfaces you need. The alternative is a hosted endpoint: we run the integration and you pay per call, with nothing upfront, which suits teams that would rather consume an API than maintain one. A typical first delivery runs one to two weeks from the point access is sorted. Tell us the app and what you want out of it, and we scope the rest — start a conversation here.

Screens we mapped against

The published store screenshots, used to confirm which surfaces the app actually exposes to a borrower.

How this brief came together

Checked in June 2026. The platform identity comes from the app's package id on Google Play and from SimpleNexus / nCino's own documentation of the borrower app, its document-to-LOS handling, and its API and webhook framework. The endpoint and pagination details (such as GET /companies and the _links cursor) come from the nCino Mortgage developer portal. The regulatory status reflects the CFPB's published reconsideration of the Section 1033 rule. Primary sources:

• nCino Mortgage API — getting started (endpoints, pagination)
• SimpleNexus — real-time data transfers via API and webhooks
• SimpleNexus — document scan and upload behavior
• CFPB — Personal Financial Data Rights reconsideration

OpenFinance Lab · interface assessment, 2026-06-08.

Other apps in the same class

Mortgage borrower and POS apps that hold comparable loan-file data; an integrator unifying this space tends to touch several. Listed for context, not ranked.

• Blend — lender-facing point-of-sale where borrowers apply and upload documents; its loan file resembles the SWF app's in shape.
• Roostify (part of CoreLogic) — digital lending front end capturing applications and document collection for lenders.
• Maxwell — POS plus fulfillment aimed at smaller lenders and credit unions, holding application and pipeline data.
• Floify — borrower POS centered on document collection and status, with per-loan checklists and milestones.
• BeSmartee — application and underwriting front end that holds borrower financial inputs.
• BNTouch Mortgage CRM — loan-officer CRM carrying borrower contact and pipeline records.
• LenderLogix — pre-approval and POS tooling with borrower and lead data.
• ICE Mortgage Technology (Encompass) — the loan origination system many of these apps sync into; the system of record for the loan file itself.

Questions integrators ask

Do you ingest loan updates in real time, or on a schedule?

Both, depending on what you are building. Milestone and document events arrive as webhook pushes the moment they fire on the platform, and we pull fuller records over REST for backfill or reconciliation. We settle the cadence per use case during the build.

Can you isolate Southwest Funding's loans from other lenders on the same platform?

Yes. The app is one tenant on a shared platform, so we scope credentials and webhook subscriptions to the Southwest Funding instance. Events and records from other lenders' builds never enter your feed.

What happens to the documents borrowers scan in?

Scanned files are written to the loan origination system rather than kept on the phone, per how the SimpleNexus app is documented. The integration reads document and condition state instead of raw files, and we design retention and minimization around that nonpublic information.

On what basis would you access a borrower's loan file?

The borrower's or the lender's own authorization, which is the dependable footing for US mortgage data. The CFPB's Personal Financial Data Rights rule that might one day cover this was enjoined in late 2025 and is back in reconsideration, so we do not build as though it governs today.