Reaching the income and donation records inside Maaser App

Every income line, donation, recipient and receipt a person enters in Maaser App lands in a per-user account and syncs across their devices in real time — the listing describes being signed into the same account on several devices at once with data kept in step. That is the whole reason the app is interesting to integrate: it is not a local calculator, it is a synced ledger of someone's giving sitting behind an authenticated backend. The developer, Sam Klein at Chill Labs, runs that backend on Firebase, which the App Store privacy section and the Exodus Privacy static report both point to (Google Crashlytics and Firebase Analytics SDKs, a policy hosted on a web.app address).

So the integration question is narrow and answerable: authenticate as the consenting user, read their Firestore collections, normalize the recurring-entry rules into real transactions, and hand back a clean feed. Below is what the account actually holds, the route we would run, and what you receive.

What the account actually holds

The fields below come from the app's own feature copy on Google Play and the App Store, mapped to where each one lives and what an integrator typically does with it.

Getting to the data

Three routes apply to an app shaped like this. They are not equal, and two of them collapse into one practical path.

Consent-based read of the synced account

The user authorizes us, we sign in to their own account against the Firebase Auth endpoint, and we read their Firestore collections with the token that sign-in returns. This reaches everything the app itself shows that person — incomes, donations, recipients, receipt references, the derived balance — because the synced copy is the source of truth. Effort is moderate; durability is good as long as the document schema holds. We arrange the consenting account or a developer test account with you at the start, so the build runs against real, in-step data.

Authorized traffic analysis to confirm the shape

Before writing a line of client code we capture the app's own requests against a consenting account to confirm the exact collection paths, field names, and the Auth flow it uses. This is documented protocol analysis for interoperability, under your authorization — it is how we pin the schema rather than guess it.

Shareable receipts as a narrow fallback

The app generates receipts that a user can share out. That is a real export, but a thin one: it is per-donation and rendered for humans, so it suits archival, not a bulk sync. We treat it as a supplement where a clean record copy is wanted, not as the main feed.

For Maaser App the sensible build is the consenting-account read, validated first by traffic capture — because the app's value is the live synced ledger, and that ledger is only reachable as the account owner. The receipt export rides along where someone wants signed documents next to the structured rows.

What ships to you

Tied to this app's surfaces, a delivery includes:

• An OpenAPI description of a clean read interface over the account — endpoints for incomes, donations, recipients and the derived balance, with the recurring rules already expanded to dated rows.
• A protocol and auth-flow report covering the Firebase sign-in step, token handling, and the Firestore document paths the records sit under.
• Runnable source for the key reads in Python or Node.js, including pagination and token refresh.
• Automated tests that exercise sign-in, a donations pull, and the recurrence-expansion logic against a test account.
• Interface documentation plus a short data-retention and consent note covering how the pull stays inside one user's scope.

A worked example

Illustrative shape only — exact project id, web API key and collection paths are not publicly disclosed and are confirmed against a consenting account during the build, not asserted here.

# 1) Sign in as the consenting user (Firebase Auth REST)
POST https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<webApiKey>
  { "email": "owner@example.com", "password": "…", "returnSecureToken": true }
# -> { "idToken": "<jwt>", "refreshToken": "…", "localId": "<uid>" }

# 2) Read that user's donations (Firestore REST)
GET https://firestore.googleapis.com/v1/projects/<project>/databases/(default)/documents/users/<uid>/donations
  Authorization: Bearer <idToken>
# -> documents[].fields: { amount, recipient, date, recurring, receiptId }

# 3) Refresh before expiry; expand recurring rules into dated rows
POST https://securetoken.googleapis.com/v1/token?key=<webApiKey>
  grant_type=refresh_token&refresh_token=<refreshToken>

# Errors worth handling: 400 EMAIL_NOT_FOUND / INVALID_PASSWORD on sign-in,
# 401 once the idToken lapses (~1h), 403 if Firestore rules reject the path.
      

What people build with it

• A bookkeeping bridge that pushes a user's donations and incomes into accounting software so the 10% figure reconciles automatically.
• A charity-side import that, with each donor's consent, pulls their recorded gifts to one organization for acknowledgement and matching.
• A year-end tax pack that bundles the donation rows with their matching receipts.
• A household dashboard combining several family members' synced ledgers into one obligation view.

Consent and the law that applies

This is a personal-records app, not a regulated financial institution, so the basis is the user's own authorization rather than any banking scheme. The records are sensitive enough to treat carefully: per the App Store listing the app collects financial information plus contact details and identifiers, linked to the user's identity. For a user in the EU that brings the data under GDPR — lawful basis is the person's consent, scope is their own account only, and we keep a consent record with a clear revocation path (a credential change or token revoke ends access). For US users the developer's home-state consumer-privacy law applies on the same consent-first footing. We minimize: pull only the collections the use case needs, log what was read, and work under an NDA where the engagement calls for one.

Things we account for in the build

• Recurring entries are rules, not rows. The app stores a recurring income or donation as a schedule. We expand that schedule into the actual dated transactions so the downstream feed matches what the app's screens display, including stop dates and edits to a series.
• Reads stay inside one user's scope. Firestore security rules tie a user's documents to their own uid, so we run the integration through the consenting account's own token — the pull only sees what that person can already see, with no escalation.
• The two platforms are on different release trains. The Android build Exodus analyzed reads as 1.2.11 while the iOS listing shows a 3.x version; we re-validate field mappings against whichever client a given account last wrote with, and add a check that flags drift when the app updates.
• Sync is real-time. We design the pull around incremental reads so newly added entries flow through without a full re-fetch each run.

App screens

Store screenshots, for reference to the surfaces named above.

What we checked

Mapped from the public Google Play and App Store listings for com.ChillLabs.Maaser, the Exodus Privacy static report for the Android build, and the listings' privacy sections, in June 2026. Source links:

• Google Play listing — Maaser App
• App Store listing — Maaser App
• Exodus Privacy report — embedded SDKs and permissions

Mapping by the OpenBanking Studio integration desk · June 2026.

Similar apps in the same space

Other apps that hold comparable giving or donation data, useful when a unified integration spans more than one of them. Listed for context, not ranked.

• Give10 — a maaser and tzedakah tracker that logs income and donations against a 10% goal and saves receipts, with optional offline use.
• EZ-Maaser — another maaser ledger for recording income and charitable giving with per-entry tracking.
• The Tzedaka App — tracks ongoing tzedakah giving and reminders, holding a personal giving record.
• Tithely — church giving platform with online and recurring donations plus per-fund records on the church side.
• Givelify — donation app holding donor histories and recurring gifts to nonprofits and congregations.
• Donorbox — fundraising platform storing donor records, recurring plans and donation receipts.
• DeductAble AI Donation Tracker — values and logs donated items for tax purposes, holding a documented donation history.
• My Well Ministry — church giving with multiple fund categories, keeping per-fund contribution records.

Questions an integrator asks

Can you pull recurring incomes and donations as individual dated entries, or only the recurrence rule the app stores?

The app keeps recurring items as a schedule rather than one row per occurrence. We expand that schedule during the build so your integration receives actual dated transactions that line up with what the app's screens show.

What does authentication look like, given Maaser App supports biometric login and being signed in on several devices at once?

Sign-in runs against the app's hosted account system using the consenting user's own credentials; biometric unlock is a device-local convenience layered on top, so it does not change the server-side token flow. Multi-device sessions mean a token issued for the integration coexists with the user's phone sessions without bumping them.

Which records actually leave the device and reach the cloud backend?

Incomes, donations, recipients, generated receipts and the account profile all sync to the backend in real time, and that synced copy is what the integration reads, so a value entered on a phone is reachable shortly after it is saved.

Does tracking a user based in the EU change how the data is handled?

Yes. EU users bring the donation and contact records under GDPR, so we scope the pull to that person's own account, keep a consent record, and minimize fields to what the use case needs. US users are handled under the developer's home-state consumer-privacy rules on the same consent-first basis.

A runnable Maaser App integration lands in one to two weeks. Source-code delivery starts at $300, billed only after we hand it over and you have confirmed it does what you need; or skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. You give us the app name and what you want out of its ledger — access and the compliance paperwork are arranged with you as part of the work. Start at our contact page.