What sits behind a Doorstep readiness score — and how to reach it

A Doorstep readiness score is a single 0–100 number, but it is assembled from seven separate inputs the app tracks for each user — affordability, savings, debt and credit, income stability, down payment, process knowledge, and market awareness. That assembly is where the value sits for anyone wanting to integrate. The score, the live buying-power figure that moves with Federal Reserve mortgage rates, and the prioritized action plan are all per-account, server-side, and recomputed over time as a person's finances change. None of it is a static export.

For an integrator — a lender wanting a warm-handoff signal, a financial-coaching product wanting to mirror a user's progress, a broker tool wanting affordability context — the practical entry point is the app's own client-server traffic under the account holder's authorization. The bank-synced layer that powers the Pro tier sits one step deeper and rides a separate consent. Both are reachable. The rest of this page names what is there and how we build against it.

What Doorstep holds per user

Authorized ways to reach the data

Three routes apply here, and they layer rather than compete.

Protocol analysis of the app's own traffic

Doorstep's computed surfaces — score, dimensions, buying power, action plan, affordability verdicts, home tags — are served to the client over an authenticated session. We capture and document that exchange against a consenting account: the login and token flow, the endpoints that return each surface, the field names and shapes. This reaches everything the app shows its user and is the durable basis for most builds, since it does not depend on a third party. Effort is moderate; the maintenance cost is re-checking when the app's front end changes.

Consented bank-data access for the synced layer

The Pro tier's automatic bank syncing implies an account-aggregation flow standing between Doorstep and the user's bank. The underlying balances and transactions are reachable through the consumer's own open-banking authorization to that aggregator — the same consent model the app already relies on. This is the route for the raw financial source data rather than Doorstep's interpretation of it. Durable, because it rests on a standing consumer consent rather than an app screen.

User-consented account access

Where a project only needs a periodic snapshot, a consented session against the user's own account — credentials supplied and authorized by that user — pulls the same computed surfaces without standing infrastructure. Lighter to stand up, lighter to retire.

For most of what people ask Doorstep for, the first route carries the work: it reaches every visible surface and answers to nobody but the consenting user. We bring the aggregator-consent route in only when a build genuinely needs the bank-side records underneath the score, and keep the consented-snapshot route for one-off or low-frequency pulls. We say which combination we would run for your case once we know what you are pulling and how often.

A worked example: reading the readiness profile

Field names and the exact auth handshake are confirmed during the build against a consenting account; the shape below is illustrative of how a readiness pull comes together.

# Illustrative — auth and field names verified during the build, not a public spec
POST /auth/token              # session bearer obtained from the app's login exchange
GET  /v1/readiness/profile
Authorization: Bearer <token>

200 OK
{
  "score": 72,                          # 0..100
  "dimensions": {
    "affordability": 0.81, "savings": 0.64, "debtCredit": 0.70,
    "incomeStability": 0.88, "downPayment": 0.52,
    "processKnowledge": 0.60, "marketAwareness": 0.74
  },
  "buyingPower": { "amount": 318000, "rateSource": "FRED", "asOf": "2026-06-01" },
  "actionPlan": [
    { "id": "a1", "title": "Reduce revolving debt", "done": false },
    { "id": "a2", "title": "Add to emergency fund",  "done": true  }
  ]
}

# 401 -> call the token-refresh endpoint, retry once, then surface the auth error
# buyingPower.asOf is stored alongside the value so a stale rate is detectable
      

What lands in your repo

Each piece is tied to a surface above, not a generic checklist.

• An OpenAPI/Swagger description of the reachable Doorstep endpoints — readiness profile, buying power, action plan, affordability lookup, home tags.
• A protocol and auth-flow report: the login exchange, the bearer/token chain, refresh handling, and (where the synced layer is in scope) the aggregator-consent path.
• Runnable source for the key endpoints in Python and Node.js — the login, the readiness pull, the affordability query for a given home price, and a paged action-plan read.
• Automated tests covering the auth refresh, a known-good readiness fetch, and the rate-as-of freshness check.
• Interface documentation a non-author can follow, plus data-retention and consent-record guidance scoped to the financial data involved.

A normalized shape for the readiness record

When a build feeds more than one downstream system, we flatten Doorstep's surfaces into a stable record so consumers do not track the app's internal field names.

{
  "user_ref": "opaque-id",
  "readiness": { "score": 72, "updated_at": "2026-06-01T14:00:00Z" },
  "buying_power_usd": 318000,
  "rate_basis": "FRED 30yr fixed (app-cited source)",
  "profile": { "dti_front": 0.28, "dti_back": 0.45, "loan_program": "conventional" },
  "linked_accounts": [ { "type": "checking", "balance_available": true } ]
}
      

The DTI figures shown here are the conventional ratios the app says it uses; we carry them as data, not as a claim about any individual lender.

Consent and the US data-rights picture

Doorstep is a US product handling a user's income, debt, savings and, on Pro, their linked-bank records. Every route we run rests on that user's documented authorization — consent captured, scoped to what the project actually needs, logged, and revocable. The bank-synced layer inherits whatever consent the user already gave the aggregator behind Doorstep's sync.

On the federal rule front: the CFPB's Personal Financial Data Rights rule under section 1033 is, at the time of writing, enjoined and back in agency reconsideration, so we do not treat it as the governing basis for this work. It is where US open banking may settle, not current law. The dependable footing today is the consumer's own consent, which is what the build is designed around — with data minimization, access logging, and an NDA where the engagement calls for one.

Engineering notes for this build

Two things about Doorstep shape how we put the integration together.

• Buying power moves with rates. Because the figure is recomputed whenever Federal Reserve mortgage rates shift, a fixed nightly poll can capture a value that is already out of date by the time it lands. We design the sync around the rate cycle and store the rate basis and as-of timestamp with every reading, so a downstream system can tell current from stale.
• The bank-sync layer is a separate consent, not a separate password. We treat the aggregator path and the app-traffic path as two distinct authorizations with two distinct refresh windows, and build the sync so neither silently lapses — the bank consent in particular has its own expiry that we schedule around.
• The score is derived, the inputs are the truth. For any project that needs to re-score or audit, we capture the profile inputs alongside the published score so the number can be reproduced rather than trusted blind.

Access to a consenting account or sandbox is arranged with you during onboarding; the build runs against that, and we re-validate the capture if the app's front end changes after delivery.

Keeping the sync fresh

Two freshness signals matter for Doorstep: the rate-driven buying-power figure, and the bank-synced balances. We attach an as-of stamp to each and expose a simple staleness flag, so a consuming system never presents a months-old number as live — the exact failure the app itself was built to avoid.

Cost and how it runs

Source-code delivery starts at $300, billed only after you have the working code in hand and are satisfied with it — runnable source, the spec, tests, and the interface docs, in a one-to-two-week cycle. The alternative is our hosted endpoints: you call our API for the Doorstep surfaces you need and pay per call, with nothing upfront and no source to maintain yourself. You give us the app name and what you want out of its data; access, consent and the compliance paperwork are arranged with you as part of the work. Tell us which surfaces matter at /contact.html and we will scope it.

App screens

Screens from the listing, useful for confirming which surfaces are user-visible.

What was checked

This mapping draws on the app's Google Play listing and its own site for the feature and tier details, Plaid's mortgage-industry material for how a bank-sync layer of this kind typically works, and the CFPB's own reconsideration notice for the section 1033 status. Reviewed June 2026.

• Doorstep on Google Play (com.trydoorstep.app)
• trydoorstep.app — product site
• Plaid — mortgage asset verification
• CFPB — Personal Financial Data Rights reconsideration

Mapped by the OpenBanking Studio integration desk · June 2026.

Other apps in the homebuying-readiness space

Same neighbourhood, each holding adjacent data a unified integration could line up alongside Doorstep.

• FinLocker — a personal financial assistant that stores credit, asset and readiness data to prepare borrowers for lenders.
• Rocket Mortgage — holds application state and loan-option modelling tied directly to a lender's financing.
• Redfin — listing data plus an affordability calculator keyed to income, expenses and down payment.
• Zillow — property records, saved searches and a home-loans pre-approval flow with verified assets.
• Realtor.com — affordability modelling joined to a large property database and local market conditions.
• NerdWallet — affordability and budgeting inputs across income, debt and down-payment cash.
• Bankrate — amortization, payoff and affordability calculators with rate data.
• Trulia — listings with a payment-and-affordability calculator and home comparison.

Questions integrators ask about Doorstep

Which Doorstep surfaces can a consented integration actually reach?

The 0–100 readiness score and its seven dimension breakdown, live buying power with the rate basis behind it, the prioritized action-plan items and their done/not-done state, per-home affordability tags, the user's financial profile inputs, and on the Pro tier the bank-synced account data that feeds the scoring.

Doorstep recomputes buying power when Federal Reserve rates move, so how do you keep a sync in step with that?

We tie the refresh cadence to the same rate cycle the app reacts to rather than a fixed clock, and we store the as-of timestamp and rate basis with each pull so a downstream system can tell a stale figure from a current one.

In the US, what is the legal basis for pulling a user's bank-synced data out of Doorstep?

The consenting account holder's own authorization. The CFPB's Personal Financial Data Rights rule under section 1033 is currently enjoined and back in reconsideration, so we do not treat it as the live basis; the consumer's documented consent is what the build rests on, with revocation honored.

If we only need the readiness score and action plan, not the raw bank feed, does that narrow the build?

Yes. Dropping the bank-synced layer removes the aggregator-consent path and leaves only the app's own computed surfaces, which is a smaller scope, fewer auth steps, and a shorter turnaround.