Reaching the giving records inside iMaaser

A gift placed through iMaaser leaves a trail worth syncing: who gave, to which charity, how much, against which year's maaser obligation, and whether the donor asked to stay anonymous. The app routes donations three ways the listing names plainly — ChatGive for a WhatsApp or SMS message, Donate4 for a four-digit charity code with no checkout form, and PaperworX for printed cards and checks. Each one lands as a row in donation history. Our work is to catch those events as they fire and turn them into clean records your systems can hold.

This is a donor-advised fund, so the money sits in a fund the sponsoring charity controls and the member advises where it goes. That shapes the data more than any payment rail does. The route we take leans on the member's authorization to their own account, with the app's CSV export filling in everything from before we connected.

What sits behind a member's iMaaser account

The surfaces below come from the app's own feature descriptions. Granularity notes reflect what the app appears to track per record; exact field shapes are confirmed during the build, not assumed.

Routes in

Two or three paths genuinely fit a fund portal like this one. None of them depends on a banking mandate, because a DAF account is not a bank account.

Donation-event capture from the authenticated portal

The richest path. Working from a member-authorized session, we observe the portal's traffic and stand up a receiver for giving events, so a ChatGive or Donate4 gift becomes a normalized record shortly after it posts. Effort is moderate; durability is good as long as we keep the capture aligned with how the app settles a gift into history. This is the path we would build the live sync on.

CSV transaction export

The app offers CSV transaction exports directly. That is the cleanest way to backfill everything that happened before go-live and to reconcile against the live feed. Low effort, very durable, but batch rather than live — so it pairs with the event capture rather than replacing it.

User-consented portal access

Where a member consents to their own data being read on their behalf, we drive the secure portal for that account and pull the same domains. This suits per-member integrations — an advisor or accountant acting for one giver — more than a fleet sync.

For most teams the answer is both of the first two together: event capture for what happens next, the CSV export for everything that already happened, reconciled so neither double-counts.

What lands in your repo

The deliverable is code that runs against iMaaser's real surfaces, not a slide deck.

• Runnable clients in Python and Node.js that authenticate a member session and pull donations, organizations, the maaser ledger and tax totals.
• A donation-event receiver for ChatGive, Donate4 and recurring gifts, writing each one as an upsert keyed on the transaction id so a replayed event lands once.
• A CSV importer that reads the app's transaction export into the same normalized schema as the live feed, for backfill and reconciliation.
• An automated test harness built on recorded fixtures, so a change in the app's responses shows up as a failing assertion you can see, not a quiet gap in your data.
• A normalized schema for gifts, charities and the obligation ledger, with the anonymity flag and memo carried through.
• Secondary, alongside the code: an OpenAPI description of the wrapped endpoints, a short auth-flow and token report, and data-retention guidance scoped to giving records.

A donation-event handler, sketched

Illustrative shape of the receiver. Field names are settled during the build against the live app, not taken from the public listing.

// Receiver for iMaaser giving events (ChatGive / Donate4 / recurring)
app.post('/imaaser/events', verifySignature, async (req, res) => {
  const e = req.body;                  // one giving event
  const record = {
    txn_id:       e.id,
    placed_via:   e.channel,           // "chatgive" | "donate4" | "recurring"
    charity_code: e.donate4_id,        // 4-digit org code shown in-app
    charity_ein:  e.recipient_ein,     // present when the app exposes it
    amount_cents: e.amount,
    currency:     e.currency || 'USD',
    memo:         e.memo,              // editable transfer memo
    anonymous:    Boolean(e.anonymous),
    maaser_year:  e.maaser_period,     // obligation year the gift counts toward
    funded_from:  e.source_id,
  };
  // a ChatGive gift sent over WhatsApp/SMS may settle into history a beat
  // later; resolveAgainstHistory reconciles so the gift is counted once
  await upsertGiving(record.txn_id, record);
  res.sendStatus(200);
});

Where it plugs in

• A day school or shul tracking which members have met their maaser pledge, pulling consented giving totals into its own dashboard.
• An accountant pulling a client's annual deductible total and acknowledgement letters straight into tax-prep, no manual re-keying.
• A nonprofit CRM reconciling DAF grants it received against the donor records on its side, matched by Donate4 code and EIN.
• A personal-finance app showing a member's maaser progress next to their income for the year.

DAF rules and the consent that actually applies

iMaaser is a donor-advised fund. The sponsoring 501(c)(3) takes legal control of a contribution once it is made, and the member keeps advisory say over where grants go — that is the IRS definition, and it is why gifts are deductible when they enter the fund rather than when a grant is sent out. The fund itself answers to IRC §4966, which puts a 20% excise tax on a taxable distribution from a DAF (per the IRS); the Treasury and IRS proposed regulations refining what counts as a taxable distribution were published in the Federal Register in late 2023 and remain in rulemaking, so we treat the edges of that definition as not yet final.

None of that governs how the account's data is read. A DAF portal is not a bank, so no account-aggregation or open-banking regime reaches it. The basis we rely on is the member's own authorization to their account, arranged with you as part of the engagement. Access is logged, data is minimized to the giving records in scope, and we work under an NDA where the engagement calls for one. The sponsoring entity behind the app is listed as I Maaser Inc of Brooklyn, NY (EIN 87-2258154, per its Daffy charity record); we confirm the operating entity at kickoff rather than assuming it.

Things this app makes you account for

Two specifics shape the build, and we handle both on our side.

Donate4 codes need resolving. The four-digit charity IDs are short and local to iMaaser, so two givers' "1234" are not the same registry entry elsewhere. We build a resolver that maps each code to a canonical identifier — the recipient EIN where the app surfaces it — and we keep a history of retired or reassigned codes so an old grant still resolves to the charity it was meant for.

ChatGive gifts arrive out of band. A donation sent by WhatsApp or SMS can register before its row settles into donation history, so the event and the ledger entry can land a beat apart. We design the capture to reconcile the two, so a single gift is recorded once and never missed when the two halves arrive at different moments.

The maaser figure also straddles a year boundary — calendar year for tax, and the giver's own accounting year for the obligation. We keep manual income inputs and automatic grant totals as separate, auditable inputs to that calculation rather than collapsing them.

How an engagement runs

A first working pull of donation history, charities and tax totals usually lands inside one to two weeks. From there the delivery splits. You can have the source itself — the runnable clients, the event receiver, the CSV importer, tests and docs — for a fixed fee from $300, paid only once it is delivered and you are satisfied with it. Or you can skip hosting anything and call our endpoints for the same data, paying per call with nothing upfront. Same integration underneath; the choice is whether you run the code or we do.

Tell us the app and what you want out of its data. Access and any authorizations are arranged with you while we build. Start an iMaaser integration

Screens we worked from

Other giving and DAF apps in the same orbit

Teams integrating iMaaser usually have one of these on the other side of a sync. Listed for context, not ranked.

• Daffy — a membership donor-advised fund holding contribution and grant history per member; the closest structural cousin to iMaaser.
• Charityvest — a DAF aimed at individuals and employers, tracking fund balances and grants out to charities.
• Givelify — a mobile giving app for faith communities, holding per-donor gift records and recurring schedules.
• Tithe.ly — church giving and management, with donation records and member-level history.
• Pushpay — congregational giving with recurring gifts and donor statements.
• Donorbox — donation forms and recurring giving, exposing donor and transaction records to the receiving nonprofit.
• EasyTithe — online church donations with admin-side giving reports.
• Fidelity Charitable — a large DAF sponsor with online grant history and annual contribution statements.
• Vanguard Charitable — a DAF sponsor holding contribution and grant activity with exportable statements.

Questions integrators ask about iMaaser

Can you capture a ChatGive or Donate4 gift as it happens, or only once it shows in donation history?

We can do both. A donation-event receiver picks up gifts close to when they fire, and we settle each one against the history row that lands afterward, which for ChatGive gifts sent over WhatsApp or SMS may arrive a beat later. For everything before go-live we backfill from the app's CSV transaction export so the record set is complete from day one.

How do you line up Donate4's four-digit charity IDs with our own organization records?

Donate4 codes are short and local to iMaaser, so we build a resolver that maps each code to a canonical identifier — the recipient EIN where the app exposes it — and we handle retired or reassigned codes so an old grant still points at the right charity in your registry.

Is iMaaser data covered by an open-banking mandate, so member consent is handled for us?

No. A donor-advised fund portal is not a bank, so no open-banking or account-aggregation regime reaches it. The dependable basis is the member's own authorization to their account data, arranged with you during onboarding. IRS donor-advised-fund rules govern how the fund itself operates, not how its data is read.

Can the running maaser or chomesh calculation be read, not just individual gifts?

Yes. The app keeps a year-long obligation figure derived from income inputs against what has been given. We expose that as a normalized field per period so a downstream dashboard can show progress, and we keep manual income entries and automatic grant totals as separate inputs so the math stays auditable.

What was checked

For this writeup we read iMaaser's own feature pages and store listings, the IRS guidance on donor-advised funds and Section 4966, and the public charity record for the sponsoring entity, in June 2026. Where the app does not publish a detail — exact field names, the operating entity behind a given account — we confirm it at kickoff rather than guessing.

• iMaaser feature site (imaaser.org)
• iMaaser on the App Store (id 6572323213)
• IRS — Donor-advised funds
• Federal Register — Section 4966 proposed rule

OpenFinance Lab — interface assessment · 2026-06-07