Getting structured loan-file data out of the Brightland Mortgage borrower app

Every document a borrower scans into Brightland Mortgage is sent straight to the lender's loan-origination system and is not kept on the phone — which already tells you where the data this app holds actually lives. The app is a white-label borrower build on the SimpleNexus platform (an nCino company); the package identifier com.simplenexus.loans.client.s__35225, per its Play Store listing, carries a company code that pins this exact lender tenant. The lender of record is Brightland Mortgage Services, Ltd. in Houston, Texas, the financing arm for Brightland Homes (formerly Gehan Homes), per its company site.

The realistic route depends on who is buying. A lender or builder-partner already has authorized access to its own SimpleNexus tenant and loan-origination system, so the durable spine there is a connector at the platform layer the customer controls. An aggregator or proptech without lender status reaches the same loan file through the authenticated borrower session under the borrower's consent. Both end at the same normalized loan record; the difference is where the authorization comes from, and we set that up with you.

What the borrower app actually holds

These are the surfaces a Brightland Mortgage borrower (or a loan officer, sales consultant or agent attached to the loan) sees in the app, mapped to where each one originates and what an integrator does with it.

The loan officer carries an NMLS identifier in the contact record; that and the milestone codes are the two fields most worth normalizing first, because everything downstream keys off them.

Authorized ways in

Protocol analysis of the authenticated borrower session

The app speaks to the SimpleNexus backend over a token-authenticated HTTP API: a credential exchange returns a bearer plus refresh token, and the loan list, document state and milestone reads hang off that. We capture the traffic against a consenting account, document the request and response shapes, and rebuild the calls as a clean client. Reach is everything the borrower sees. Effort is moderate. Durability is tied to the app front end, which we account for in maintenance.

User-consented access for an aggregator

Where the customer is a proptech or aggregator without lender status, a borrower authorizes the connection and we drive the same authenticated flow on their behalf to sync that one loan file. Reach is the consenting borrower's loan only. It stays stable while the consent and credentials hold, and the sync is designed around the token-refresh window so it does not lapse unnoticed.

Lender-side platform connector

When the customer is the lender or a builder partner, the cleaner integration sits at the SimpleNexus and LOS layer the customer already controls — milestone events and token-authenticated data pulls into that tenant. Reach is the full pipeline for that lender. This is the most durable option because it does not depend on the consumer app's front end at all.

Native export as a fallback

The app issues borrower-facing PDFs such as pre-approval and status letters. Where a structured feed is not warranted, parsing those documents is a low-effort fallback that still yields status and the headline loan terms.

For a lender or builder customer we would build the platform-side connector first and treat the borrower-session client as the verification layer; for an aggregator the consented borrower session is the only honest path and the one we would scope.

On the wire

Shapes below are confirmed during the build and the values are illustrative; the version segment varies by platform release and the milestone vocabulary is the lender's own LOS configuration.

# Brightland Mortgage borrower session (SimpleNexus tenant, company code per the
# Play listing). Endpoint paths normalized for readability.

POST /api/v?/auth/token              # username + password -> bearer + refresh
  -> 200 { "access_token":"...", "refresh_token":"...", "expires_in":3600 }

GET  /api/v?/loans                   # loans visible to this borrower
  Authorization: Bearer <access_token>
  -> 200 [ { "loanId":"...", "status":"Processing",
             "milestone":{ "code":"DOCS_OUT", "ts":"2026-05-12T17:04:09Z" },
             "loanOfficer":{ "name":"...", "nmls":"..." } } ]

GET  /api/v?/loans/{loanId}/documents
  -> 200 [ { "docId":"...", "label":"Pay stub",
             "state":"RECEIVED", "uploadedAt":"..." } ]

POST /api/v?/loans/{loanId}/documents   # multipart scan -> routed to the lender
                                        # LOS, not retained on the device
  -> 202 { "docId":"...", "state":"QUEUED" }

# 401 -> re-mint via /auth/token with the refresh grant.
# milestone.code is lender-configured; we map it to a stable enum so a label
# rename in the LOS does not break a downstream consumer.
        

The normalized record we hand back collapses that into one shape: a loan with a stable status enum, a document list with per-item state, the assigned contacts, and a change feed keyed on milestone code plus timestamp.

What you receive

• An OpenAPI specification covering the borrower session: token exchange and refresh, loan list, per-loan documents and the milestone read.
• A protocol and auth-flow report describing the bearer/refresh chain, expiry behaviour and the 401 re-mint path as they appear on this tenant.
• Runnable source for the key endpoints in Python and Node.js — login, status poll, document state and the upload call — with the milestone normalization included.
• Automated tests against the recorded contract so a shape change is caught before it reaches your pipeline.
• Interface documentation: the normalized loan schema, the milestone-code map for Brightland's configuration, and worked request and response examples.
• Data-handling guidance: what is nonpublic personal information here, what to log, and consent-record structure for the consented-borrower route.

Worked scenarios

• A builder partner wants its sales team to see live loan status for buyers in a community. We connect at the lender's SimpleNexus tenant, take milestone events, and push a normalized status feed into the builder's CRM.
• A document-tracking tool needs the per-loan required-document list and which items are still outstanding. We expose the document-state surface as a clean endpoint with completeness flags.
• A homebuying app wants a borrower to link their Brightland loan and see milestones in-app. The borrower consents, and the consented-session client returns the loan record on a refresh schedule.
• A reporting team wants loan-officer attribution by NMLS identifier across the pipeline. We normalize the assigned-contact record and join it to milestone history.

Engineering notes specific to this build

A few things shape how we scope this app, all handled on our side as part of the work:

• The app is one tenant of a shared SimpleNexus borrower build. We pin the integration to Brightland's company code so the milestone set, document checklist and assigned-contact roles match this lender's LOS, not a generic SimpleNexus default that would be subtly wrong.
• Milestone labels and ordering are lender-configured in the loan-origination system. We map Brightland's milestone set to a stable normalized enum, so a label rename or reordering on the lender side is absorbed in the mapping rather than breaking downstream consumers.
• Scanned documents go directly to the LOS and are not retained on the device. The integration therefore reads document state and metadata from the loan record rather than any local store, and we design the sync around that.
• SimpleNexus ships borrower-app updates on its own cadence. Our maintenance includes a scheduled re-confirmation of the request and response shapes against a live session, so a moved field surfaces to us before it surfaces to your data.
• Access is arranged with you at onboarding — a consenting borrower account, or the lender's own SimpleNexus environment if you are the lender or a builder partner. The build runs against whichever of those fits, and that decision is part of the engagement, not something you settle in advance.

Data-handling posture

Brightland Mortgage Services is a US mortgage banker, so the loan file is nonpublic personal information under the Gramm-Leach-Bliley Act and the lender's privacy notice — name, contact, income documents, loan terms and status. We work only through authorized, documented or user-consented access, keep an access and consent log, minimize fields to what the integration needs, and sign an NDA where the engagement calls for it. The US consumer financial data rights rule the CFPB published is centered on deposit and transaction accounts rather than the mortgage-origination pipeline, so it does not provide a regulated feed for this app's data; that is precisely why the authorized route here is interface integration and user-consented access rather than a mandated open-banking endpoint. For the consented-borrower route we keep a per-borrower consent record with scope and a revocation path, and the sync stops when consent is withdrawn.

Cost and timeline

The concrete deliverable here is a documented, runnable client for the Brightland Mortgage borrower endpoints — token exchange, the loan and milestone read, document state and the upload call — with the milestone normalization and tests included. Source-code delivery starts at $300 and is billed only after the code is in your hands and you are satisfied with it. The other option is our hosted endpoints billed per call, with nothing upfront. A typical build runs one to two weeks. Tell us the app and what you need from its loan data on the contact page and we will scope the route with you.

How this was checked

Verified in May 2026 against the app's store listings, the SimpleNexus and nCino platform documentation describing the borrower app, document routing and milestone behaviour, and Brightland Mortgage Services' own company site for the lender of record. Primary sources opened:

• Brightland Mortgage on Google Play
• SimpleNexus document scan and upload behaviour
• SimpleNexus platform API and webhooks overview
• Brightland Mortgage Services — about the lender

Mapped by the OpenBanking Studio integration desk, May 2026.

Comparable apps in the same space

Lenders and proptechs usually want one normalized loan record across several of these, which is the same normalization work described above:

• Rocket Mortgage — direct-to-consumer origination and servicing, with application, document and status data behind a borrower account.
• Better Mortgage — online origination holding the application, conditions and milestone state per loan.
• loanDepot mello — borrower portal with application progress, document upload and loan status.
• Blend — a lender-deployed origination experience; the borrower app holds the application and conditions for that lender.
• Maxwell — point-of-sale borrower portal with document collection and status tracking used by independent lenders.
• Floify — branded borrower portal for applications, automated document collection and status updates.
• Roostify — digital origination with a borrower portal for document upload and loan tracking.
• Cornerstone Home Lending — a builder-aligned lender app in the same purchase-mortgage niche as Brightland, with comparable application and status data.

App screens

Questions integrators ask

Is the data in Brightland Mortgage the same as a generic SimpleNexus borrower app?

No. Brightland's app is one white-label tenant of the SimpleNexus borrower build, keyed to a company code in the package identifier. The milestone names, document checklist and assigned contacts come from Brightland's own loan-origination configuration, so we pin the integration to this tenant rather than a generic SimpleNexus default — otherwise the status vocabulary and required-document list would not match this lender.

Can the integration see real-time loan-status changes or only a snapshot?

Milestone transitions originate in the lender's loan-origination system and flow through SimpleNexus into the app. For a lender or builder-partner customer we connect at the platform layer the customer already controls and take milestone events as they fire. For a consented-borrower setup we read the per-loan status on a schedule and emit a change event when a milestone code or timestamp moves.

What happens to the integration when SimpleNexus pushes an app update?

The borrower app is updated regularly and a capture can shift when it does. Maintenance includes a scheduled check that re-confirms the request and response shapes against a live session before any change reaches a downstream consumer, so a renamed field or moved endpoint is caught by us rather than by your data pipeline.

Do you need Brightland's lender environment or a borrower login to build this?

Access is arranged with you during onboarding — either a consenting borrower account or the lender's own SimpleNexus environment, whichever fits who you are. To scope and quote the work we only need the app name and what you want out of the loan data; the access path is worked out together as part of the engagement.