Reaching the points and goals Debbie keeps for each member

Debbie's own launch coverage puts it past 200,000 users who have together pulled more than $2.3M in cash out of a points balance — a balance that lives only on Debbie's servers, not in any bank a member linked. That ledger, the monthly streak goals it scores, and the money-psychology profile behind it are the parts a sponsor credit union, a financial-wellness platform, or a rewards aggregator would want to read programmatically. None of it is exposed on a public page. It sits behind an authenticated account, which is exactly the kind of interface this studio integrates.

The bottom line: the valuable data is Debbie's behavioural ledger, and the dependable way to it is the authenticated mobile interface, accessed with a consenting member. We would build against that interface, normalize the points and goals model, and hand back source you can run. The Plaid-linked bank balances are reachable too, but they are the commodity part — the points, multipliers and streak scoring are what only Debbie has.

The data Debbie keeps per member

Mapped from the app's own description and its Rewards 2.0 launch material. Names follow how Debbie labels things where that is known.

Reaching it — the routes that apply here

Authorized interface integration of Debbie's authenticated traffic

This is the route we would take. With a consenting Debbie account, we observe the authenticated calls the app makes for the points balance, the monthly streaks, Pathway progress and the linked-account list, then implement a clean client against them. Reachable: effectively everything a member sees in-app. Effort: moderate — token-based session auth, refresh handling, and a points history that pages. Durability: good between app releases, with maintenance when Debbie ships a new build. Access is arranged with you during onboarding, against a consenting account or a sponsor test environment.

User-consented account access

Where the deployment is member-facing — a sponsor credit union pulling its own members' Debbie progress — each member authorizes the sync against their own session. Same surfaces as above; the difference is consent is collected per member and logged, which suits a sponsor rollout.

User-permissioned access to the underlying linked accounts

If the target is the bank-side balances rather than Debbie's ledger, the member-permissioned aggregation path (the same Plaid-style consented bank link Debbie itself uses) reaches balances and transactions directly. We would only lead with this when the requirement is the raw account, not the rewards behaviour — for the points and streak scoring, Debbie's own interface is the only place that figure exists.

Recommendation, in plain terms: build the authenticated-interface client as the core, collect consent per member for a sponsor deployment, and treat the bank-side path as a supplement only when raw balances are explicitly in scope.

The calls, roughly

Endpoint and field names below are illustrative — the exact routes are confirmed during the build by observing the authenticated app. The shape, the auth model and the paging behaviour are what matter here.

POST /v1/auth/session
  body: { identifier, secret }            -> { access_token, refresh_token, member_id }
  401  -> POST /v1/auth/refresh { refresh_token }

GET  /v1/rewards/balance                  # Authorization: Bearer <access_token>
  -> { points: 7420,
       cash_equivalent_usd: 74.20,
       cashout_threshold_usd: 50,
       state: { earned, pending, redeemed },
       sponsor_multiplier: 1.5 }          # 1x base, 1.5x-2x on eligible partner accounts

GET  /v1/goals?period=2026-05             # monthly streaks
  -> [ { type: "savings",       target_usd, progress_usd, met: false },
       { type: "card_payment",  target_usd, progress_usd, met: true  } ]

GET  /v1/pathway/progress                 # weekly money-psychology modules
GET  /v1/accounts                         # Plaid-linked debt & savings, balances
GET  /v1/rewards/history?cursor=...       # paged accrual + cash-out events

# error handling: 401 -> refresh once then re-auth; 429 -> backoff;
# a Plaid item in re-auth surfaces as account.status = "needs_reauth"

What lands at the end of the build

Concrete artefacts, tied to Debbie's actual surfaces:

• An OpenAPI specification covering session auth/refresh, the rewards balance and history, monthly goals, Pathway progress and linked accounts.
• A protocol and auth-flow report: the token chain, refresh trigger, the paging cursor on points history, and how a Plaid re-auth state shows up.
• Runnable source for the key endpoints in Python and Node.js — authenticate, pull the balance, walk the goals and the paged history.
• Automated tests against recorded responses, including the sponsor-multiplier and cash-out-threshold cases.
• Interface documentation a non-author can run, and data-retention guidance for the member data above.

A normalized shape for points and goals

Debbie's raw responses are app-shaped; what a partner system wants is stable. We deliver a normalized model so the sponsor multiplier and pending/redeemed split do not leak into your code:

{
  "member_ref": "opaque-id",
  "sponsor": { "id": "cu-partner", "multiplier": 1.5 },
  "rewards": {
    "balance_points": 7420,
    "cash_equivalent_usd": 74.20,
    "cashout_threshold_usd": 50,
    "earned_usd": 96.10, "pending_usd": 4.00, "redeemed_usd": 22.10
  },
  "goals_2026_05": [
    { "type": "savings", "target_usd": 200, "progress_usd": 140, "met": false },
    { "type": "card_payment", "target_usd": 150, "progress_usd": 150, "met": true }
  ],
  "linked_accounts": [ { "kind": "debt", "balance_usd": 3120.55, "link": "ok" } ]
}

Authorization, and where US data rights actually stand

The dependable basis here is the member. A Debbie user has already linked their debt and savings accounts through Plaid and holds the Debbie account that carries their points, goals and sponsor match; their authorization to a sponsor or partner is what the integration runs on, recorded and revocable. Debbie's program is tied to specific sponsoring credit unions, so consent is scoped to that relationship, and we keep the data set minimal — the points, goals and the figures a use case needs, not the whole profile by default. Handling is logged, with an NDA in place where the engagement needs one. As for a statutory route: the US Personal Financial Data Rights rule (CFPB §1033) is not in force — it was enjoined in late 2025 and is back in agency reconsideration, with compliance dates frozen — so it is where consumer-permissioned access in the US may eventually be codified, not something this integration can lean on today. We rely on the member's own authorization, which is settled, and treat §1033 as a forward question to watch for Debbie's sponsor model.

What we handle on a Debbie build

Specific things this app makes us account for, all on our side of the engagement:

• Per-sponsor reward rules. Multipliers differ by sponsor — a 1x base versus 1.5x–2x on eligible partner accounts. We map the sponsor context per member so two members on different credit unions report the multiplier that actually applied, rather than a flat assumption.
• The points-to-cash ledger. Points convert to cash, cash-out opens at $50, and cash-outs are unlimited. We model earned, pending and redeemed as distinct states so a partner reading the ledger does not double-count a payout that is still settling.
• Plaid link freshness. Linked accounts can drop into a re-auth state on Plaid's side. We design the sync to detect that and surface it rather than silently losing an account's balance; the access used for the build is arranged with you during onboarding against a consenting account or a sponsor test environment.
• App releases. Debbie ships new app versions; routes and fields move. Keeping the captured calls current after an update is part of the engagement and handled by us, on a short turnaround, not a from-scratch rebuild.

Cost and cycle

A Debbie build runs one to two weeks end to end: capture the authenticated calls, normalize the points and goals model, ship runnable source with tests and docs. You can take it as source-code delivery starting at $300, where you pay only after delivery once the integration is in your hands and you are satisfied with it. Or run it as a hosted API you call, with no upfront fee and billing per call. Either way the only things we need from you to begin are the Debbie target and what you want out of its data; access and the compliance paperwork are arranged together with you. Tell us the use case at /contact.html and we will scope it.

Screens we worked from

Public store screenshots, used to read Debbie's surfaces. Select to enlarge.

Where Debbie sits among savings-and-payoff apps

Same category, named for keyword reach and to frame a unified integration — not ranked. Each holds account-linked data a partner might want normalized alongside Debbie:

• Changed — rounds up purchases and applies the spare change to debt; holds linked-account round-up history and payoff progress.
• Rocket Money — aggregates linked accounts, subscriptions and bill data behind an account; rich transaction surface.
• EveryDollar — zero-based budget and a debt-elimination plan; holds budget categories and a debt schedule.
• Qapital — rule-based automatic savings; holds custom savings rules and goal balances per linked account.
• Acorns — round-up investing and savings; holds portfolio, round-up and recurring-deposit records.
• Long Game — prize-linked savings with a game layer; holds a savings balance and reward-entry history.
• Yotta — savings with a lottery-style reward mechanic; holds balances and reward draw records.
• Undebt.it — debt-payoff planner; holds a structured debt list, payoff schedule and snowball/avalanche plan.

A studio that can read Debbie's ledger can normalize these into one consented progress-and-rewards model.

Questions integrators ask about Debbie

Is the points balance read from Debbie, or recomputed from bank data?

It is Debbie's own server-side ledger. Accrual rules, the sponsor multiplier, pending versus redeemed state and the cash-out threshold all live on Debbie's backend, not in the linked bank feed. We read that ledger from the authenticated interface rather than trying to reconstruct it from Plaid transactions, because the reconstruction would not match Debbie's own figure.

Do reward multipliers change depending on which credit union sponsored the member?

Yes. The launch material describes a 1x base on dollars saved or applied to a card and 1.5x to 2x on eligible partner bank or credit-union accounts. The sponsor a member was matched to is part of their record, so we carry that context per member and the integration reports the multiplier that actually applied.

How do you reach a member's linked debt and savings accounts?

Through the consenting member's own Debbie session. Debbie links external accounts via Plaid, so balances, the debt-payoff figure and quick-win signals such as a credit-score check are surfaced inside Debbie. We model them as Debbie presents them and keep the Plaid item re-auth in mind so a stale link does not silently drop an account.

If Debbie ships a new app version, does the integration stop working?

App releases do move things around. Keeping the captured calls current after a Debbie update is part of the engagement and handled on our side; a change of that kind is a one-to-two-week turnaround, not a rebuild. Tell us what you need from Debbie's data at /contact.html.

Sources and when we checked

Compiled on 2026-05-19 from Debbie's own program material and its Rewards 2.0 launch coverage, plus the current US data-rights position. Reviewed: Debbie's Rewards 2.0 launch write-up (techli), Debbie's reward program terms (joindebbie.com), the CFPB's reconsideration page for the Personal Financial Data Rights rule (consumerfinance.gov), and a legal alert on the §1033 injunction and reconsideration (Cozen O'Connor). Figures such as user count, cash paid out and partnership count are as reported in Debbie's launch coverage, not independently audited here.

OpenBanking Studio integration desk · mapping reviewed 2026-05-19.