Reaching the cash-advance and income data inside Grant Cash Advance

Every advance on Grant Cash Advance moves through a server-tracked lifecycle: an eligibility read taken off the user's linked bank account, a requested amount, a claim, a delivery-speed choice, then an automated repayment pull when the next paycheck lands. None of that lifecycle exists on the device — it is state held by Grant Money, LLC's backend, recomputed as the user's deposit history changes. That is the data an integrator actually wants, and it is the spine of this brief.

The app is operated by Grant Money, LLC, described in public filings and the Kikoff company blog as a subsidiary of the San Francisco fintech Kikoff; the Android package id is com.kikoff.theseus, per its Play Store listing. It is an earned-wage-access product, not a lender — advances run roughly $25 to $500 by the app's own description, with practical first-time amounts much smaller and a limit that grows with repayment history.

The bottom line is simple. The product the integrator cares about — what is owed, when it auto-repays, whether an Express transfer settled — lives only on Grant's own backend. We center the build there and add the bank-side income feed when a client also wants the raw signal eligibility is derived from.

Where Grant Cash Advance keeps user data

Each row below is a surface the app exposes to its own users; the integration mirrors it through an authorized route.

Getting at the data: the routes that apply here

Three routes are real for this app. They are not equivalent, and only one carries the product end to end.

Authorized protocol analysis of the app's own traffic

The app's client talks to Grant's backend over an authenticated session. Mapping that exchange under the account holder's authorization reaches everything the user sees: eligibility, the advance ledger, the repayment schedule, Express transfer status, Earn Cash points and the Plus Bills & Spending view. Effort is moderate; durability is good once we pin the auth and re-check it on client updates. We set up a consenting test account and capture under written authorization as part of the engagement, and we map the token issue and refresh chain plus any device binding.

User-consented bank-aggregator feed

Cash-advance apps in this category link the user's bank through an aggregator of the Plaid type, with read access the user grants and can revoke; the exact provider is confirmed during the build. This route returns the income and transaction signal eligibility is computed from — useful, regulated, durable — but it does not contain Grant's own advance balance or repayment timeline. It complements the first route; it does not replace it.

Native in-app history as a fallback

Where the app surfaces its own advance history and the Plus Bills & Spending breakdown, those views are a thin fallback for read-only reconciliation when a full session map is not warranted. It is the narrowest option and we say so plainly.

On this app the protocol route is the one that actually carries the product, because the outstanding balance and the payday repayment date only exist on Grant's backend. We build there first and bolt the aggregator feed on when a client wants the raw bank-side income alongside it.

What lands in your repository

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger specification covering the eligibility, advance-ledger, repayment, Express-transfer and points endpoints as observed.
• A protocol and auth-flow report: how the session token is issued and refreshed, any device binding, and the cookie or header chain that keeps a session alive across an advance request and claim.
• Runnable source for the key endpoints in Python and Node.js — fetch eligibility, list advances, read a repayment schedule, poll an Express transfer.
• Automated tests, including the awkward cases: a limit step-up, an excluded-state response, a free-tier token hitting Plus-only Bills data, a pending transfer over a settled advance.
• Interface documentation a non-author engineer can run from, plus data-retention and consent guidance written for an EWA data flow.

A worked example: reading eligibility and the advance ledger

Illustrative shapes, confirmed and pinned during the build against a consenting account — field names are normalized in delivery, not guessed at here:

POST /v1/session/refresh
  Authorization: Bearer <short-lived access token>
  X-Device: <bound device id>
  -> 200 { "access_token": "...", "expires_in": 900 }

GET /v1/advance/eligibility
  -> 200 {
       "state": "TX",
       "eligible": true,
       "available_advance": 75.00,
       "max_advance": 150.00,
       "limit_step": { "from": 50.00, "to": 75.00, "at": "2026-05-09T14:02:11Z" }
     }
  -> 200 { "state": "NV", "eligible": false, "reason": "state_unavailable" }

GET /v1/advance?status=outstanding
  -> 200 { "advances": [
       { "id": "adv_8842", "amount": 75.00, "claimed_at": "2026-05-10T16:20:03Z",
         "outstanding": 75.00,
         "repayment": { "scheduled_date": "2026-05-24", "method": "ach_debit", "status": "scheduled" },
         "express": { "selected": true, "fee": 4.99, "status": "settled" } } ] }

# error handling: re-auth on 401, back off on 429,
# treat repayment.status in {failed,retrying} as a reconciliation event

The state-gate branch is not an edge case here — it is a first-class response, because the product genuinely does not operate in seven jurisdictions.

Licensing and the consent we work under

Grant Money, LLC operates as an earned-wage-access provider, not a credit lender. It holds state income-based-advance licensing; in California it operates under an Income-Based Advance license (No. 04-CCFPL-2685193-3481156, per state licensing records) issued by the Department of Financial Protection and Innovation. In December 2025 the CFPB took the position, in a Federal Register notice on Truth in Lending and EWA, that covered earned-wage-access products are not credit under TILA and Regulation Z, withdrawing an earlier 2024 proposal; the state licensing layer remains a moving patchwork and we treat its fee and disclosure specifics as live, not settled. We do not assert any state fee cap as a fixed number on this page.

The integration runs under the account holder's authorization or a consenting test account. The aggregator feed, where used, runs on consent the user grants and can revoke. We take only the advance, repayment, income and identity fields the integration needs, keep consent and access logs, and work under an NDA where the engagement calls for one. That is how the studio operates, not a gate the reader has to clear.

Things we plan around on this build

These are specific to Grant Cash Advance, and each is handled on our side:

• The state gate. The product is unavailable in CT, DC, MD, NV, RI, SC and WI per the app's disclosure, and eligibility logic differs with state licensing. We model the gate as a first-class response so an excluded-state call returns clean unavailability rather than a malformed eligibility object.
• A limit that moves. Advances start small and step up with on-time repayment. We treat the limit as a volatile server value and design the sync to capture each step-up with its timestamp, instead of caching a stale ceiling.
• Paycheck-detected repayment. The auto-debit is tied to a detected deposit, not a fixed calendar date. We align the sync window to the observed pay cadence so a predicted repayment date stays accurate when payday drifts.
• Tiered surfaces. Bills & Spending exists only for $9.99/month Plus subscribers. We scope the build per tier so a free-tier token does not silently return empty Bills data and get misread as "no transactions".
• Express as its own state machine. The transfer has a status and fee tier independent of the advance. We represent transfer state separately so a settled advance with a still-pending transfer is modelled correctly.

What teams actually build with this

• A budgeting app folding Grant's payday repayment debit into a forward cash-flow forecast so the user is not surprised on payday.
• A lending or PFM product reading a user's outstanding Grant advances to show a true available balance and avoid stacking obligations.
• A financial-wellness dashboard reconciling EWA usage and the $9.99 Plus plus Express fees as recurring costs against income.
• A debt-management tool ingesting the repayment schedule to time other obligations around the auto-debit.

Keeping the sync honest

Eligibility and the limit are recomputed from bank activity, so they are volatile — we poll them on the user's pay cadence rather than on a fixed clock. Express transfer status is the fastest-moving object on the platform; the app's own disclosure describes the large majority of Express transfers completing within about a minute, so we use a short poll window right after a claim. When Grant ships a new client build we re-capture and diff the auth and the ledger shapes before any change reaches your pipeline, so a silent field rename does not become your incident.

Screens we worked from

Public store screenshots used while mapping the surfaces above. Select to enlarge.

The cash-advance app neighbourhood

Same-category apps an integrator usually encounters alongside Grant Cash Advance; named for ecosystem context, not ranked.

• EarnIn — pay-period advances against earned wages, with linked-account income tracking behind eligibility.
• Dave — small advances plus budgeting and side-gig connections, holding a similar advance and repayment ledger.
• Brigit — advances gated on confirmed recent payroll deposits, with overdraft alerts and a credit-builder record.
• MoneyLion — Instacash advances alongside a broader account and offers stack, server-held per user.
• Albert — instant advances after cash-flow analysis, with savings and budgeting state behind an account.
• Klover — advances funded against engagement data, no subscription, with its own points-style ledger.
• Cleo — subscription-gated advances and an AI budgeting view over linked transactions.
• Empower (rebranded Tilt) — subscription advances with same-day funding and a spending view.
• Possible Finance — installment-style advances reported to credit, with a distinct repayment schedule object.
• Gerald — fee-free, low-cap advances tied to in-app activity and a linked bank account.

Each holds a comparable shape — advance ledger, repayment timeline, linked-account income — which is why teams ask for one normalized interface across several of them.

Questions integrators ask about Grant Cash Advance

Grant's advance limit moves over time — can the integration track the step-ups?

Yes. The available and maximum advance are recomputed server-side from the linked bank account, and they step up as on-time repayments accumulate. We model the limit as a moving value rather than a static cap, and the sync captures each step-up event with its timestamp so a downstream balance never lags the real entitlement.

Does the bank-linking path replace reading Grant's own advance ledger?

No. A user-consented aggregator connection returns the bank-side income and transaction signal that eligibility is derived from. It does not contain the outstanding-advance balance, the claim state, the Express transfer status or the payday repayment schedule — those live only on Grant's backend, which is why the protocol route carries the product and the aggregator path is a complement.

How is the licensing and data-rights picture handled for an earned-wage-access app like this?

Grant Money, LLC operates under state income-based-advance licensing — including a California Income-Based Advance license (No. 04-CCFPL-2685193-3481156, per state licensing records) from the DFPI — and under the CFPB position issued December 2025 that covered earned wage access is not credit under the Truth in Lending Act. We work strictly under the account holder's authorization or a consenting test account, take only the advance, repayment and income fields the integration needs, and keep consent and access logs.

Grant is not offered in every state — does the integration handle the excluded ones?

Yes. The product is unavailable in CT, DC, MD, NV, RI, SC and WI per the app's own disclosure, and eligibility logic varies with state licensing. We map the state gate so a call from an excluded state returns a clean unavailable result instead of a broken eligibility response, and tests cover that path explicitly.

How this brief was put together

Checked in May 2026 against the app's own store listing and site, EWA regulatory primary sources, and the aggregator documentation that the bank-link route would rely on. Primary sources opened:

• Grant Cash Advance — Google Play listing
• grantcash.com — how the cash advance works
• Federal Register — TILA non-application to EWA (Dec 2025)
• Plaid — earned wage access use case

Mapped by the OpenBanking Studio integration desk, May 2026.

A build for Grant Cash Advance lands as runnable source for the eligibility, advance-ledger and repayment endpoints, an OpenAPI specification, the protocol and auth-flow report, and the test suite — inside one to two weeks. Source-code delivery starts at $300 and is paid after delivery, once you have it and you are satisfied; if you would rather not host it, the same surfaces are available as a pay-per-call API with nothing upfront. Tell us the app name and what you need from its data on the contact page and we arrange the authorized access with you from there.