Reaching per-user gold holdings and transactions inside Jar

What a Jar account actually holds

A Jar account stores 24K digital gold as a fractional grams balance, bought in amounts from ₹10, with a government GST of 3% and a buy-sell spread of roughly 2–3% applied on each transaction, per the app's Play Store listing. That ledger is the asset most integrators want, and it is the part that originates with the custody partner rather than with Jar itself. Around it sit the savings automation, payments, and credit surfaces that make Jar an all-in-one money app.

The table maps the surfaces a consented account exposes and what each is good for.

Authorized routes to the data

Three routes apply to this app, and they carry different parts of the account. We size each one to what it can reach, then run the build on the combination that fits your requirement.

User-consented interface integration

The gold ledger, savings schedule, and gold-rate surfaces are reached through authorized analysis of the app's own client-server traffic, under the account holder's consent. This covers the data that has no regulated data-sharing rail behind it. Effort is moderate; durability depends on the app's release cadence, which we plan maintenance around.

Account Aggregator consent for partner-held finance data

Where a surface routes through a regulated partner — the lending NBFC or the insurer — that data can move over India's Account Aggregator framework when the partner participates as a financial information provider. This route is consent-native and durable, and it is the cleaner basis for loan and insurance records than scraping a screen.

Native export, where present

Transaction histories that the app lets a user download serve as a verification fallback and a way to backfill a synced ledger. It is narrow but cheap to wire in.

For most briefs we open on the consented interface route, because the digital-gold balance — the reason people integrate Jar at all — only lives there, and we layer Account Aggregator consent on top for the lending and insurance pieces so those ride a regulated rail. Native export stays in reserve for reconciliation.

What you receive

Each engagement ends with code you can run, not a report. For Jar that means:

• An OpenAPI specification covering the holdings, savings-schedule, UPI, loan, and rate surfaces you ask for.
• A protocol and auth-flow report: the token issue and refresh chain, session handling, and how the SafeGold-sourced fields are distinguished from Jar-native ones.
• Runnable source for the key endpoints in Python or Node.js — holdings read, transaction pull, rate snapshot.
• Automated tests against the responses we observed during the build.
• Interface documentation and consent/data-retention guidance written for an India deployment.

A worked example: reading the gold balance

Illustrative shape only — exact field names and the auth handshake are confirmed against live traffic during the build.

POST /v2/auth/token        # token issued after OTP-verified login
  { "device_id": "...", "grant": "refresh", "refresh_token": "..." }
  -> { "access_token": "...", "expires_in": 1800 }

GET  /v2/portfolio/gold     # holdings + last computed valuation
  Authorization: Bearer <access_token>
  -> {
       "balance_grams": 1.8742,         // 24K, partner-custodied
       "rate_per_gram_inr": 6000,       // refreshed ~every minute
       "rate_as_of": "2026-06-26T09:14:05+05:30",
       "spread_pct": 2.5,               // buy-sell, carried separately
       "gst_pct": 3.0
     }

# valuation is stored against rate_as_of, never re-quoted on a later rate.
# 401 -> refresh once via /v2/auth/token, then retry; repeated 401 -> re-consent.

Where this gets used

• A wealth app that wants a consolidated holdings view pulls the grams balance and values it against the timestamped rate.
• A budgeting tool mirrors the daily/round-off savings schedule and the UPI spend ledger into one cash-flow picture.
• A lender doing affordability checks reads the existing Jar loan's outstanding balance and EMI over Account Aggregator consent.

Things we plan for on this build

Two details shape how we scope a Jar integration, and we handle both rather than hand them to you.

• We split the model along the SafeGold custody boundary. The grams balance, rate, and spread originate with the digital-gold partner, while the savings schedule and round-off rules are Jar-native — so we tag each field by source and keep the two reconcilable, which matters when a balance has to be audited later.
• We design the sync around the minute-level rate refresh and the 2–3% spread, timestamping every valuation against the rate that produced it. A balance is never carried forward against a price it was not computed on.
• We scope the lending and insurance surfaces separately, because they route through a regulated NBFC and an insurer whose consent and data-retention rules differ from the gold ledger and from each other.

Consent and regulatory status

Jar operates in India, and the relevant data-sharing rail is the Reserve Bank of India's Account Aggregator framework, run through licensed NBFC-AA consent managers — the consent-native path for bank, NBFC, and insurance data. Digital gold itself sits outside that scope: it is not a notified security, which SEBI restated in its November 2025 caution that digital-gold products are unregulated. So the dependable basis for the gold ledger is the account holder's own consent, captured and logged, with access scoped to the surfaces you need and revocable. We work authorized and data-minimized, keep consent and access records, and sign an NDA where the engagement calls for one. For the loan and insurance data, Account Aggregator consent gives a cleaner, expiry-bound basis than reading a screen.

Working with us

Source-code delivery starts at $300, billed only after we hand over working code and you have checked it does what you needed. If you would rather not host anything, the pay-per-call option lets you call our endpoints and pay per call, with no upfront fee. Either way the cycle is one to two weeks. Tell us the target — Jar, and which surfaces you care about — and the access and compliance steps are arranged with you as the project runs. Start the conversation on the contact page.

Interface evidence

Store screens used while mapping the surfaces above.

Similar apps in the same data space

These sit in the digital-gold and savings category and share data shapes with Jar, which is why a single normalized integration tends to span several of them. Listed for ecosystem context, not ranked.

• Gullak — automatic micro-savings into digital gold, including save-on-spends round-ups; a grams balance much like Jar's.
• Tanishq DigiGold — gold saved by value and redeemable toward jewellery, with a per-user accumulation ledger.
• MMTC-PAMP — digital gold with a holdings balance and redemption records.
• Groww — digital gold via an Augmont partnership alongside investment holdings.
• PhonePe — digital gold and a heavy UPI transaction trail in one account.
• Paytm — gold balance plus wallet and UPI activity.
• Freo — savings and gold features with linked credit data.
• Airtel Payments Bank — gold purchases alongside a payments-bank ledger.
• Pluto Money — automated gold savings paired with financial-education tracking.

Questions integrators ask

Does Jar's gold balance travel over India's Account Aggregator rails?

Not the gold itself. Digital gold is not a notified security, so it sits outside the Account Aggregator FIP scope, and the dependable basis for the holdings ledger is the account holder's own consent plus authorized interface integration. Where a surface routes through a regulated partner — the lending NBFC or the insurer — that data can ride consent where the partner acts as a financial information provider.

How do you keep a stored gold valuation from going stale?

Jar refreshes the per-gram 24K rate about once a minute and a buy-sell spread of roughly 2 to 3 percent applies, per its Play Store listing. We timestamp every stored valuation against the exact rate it was computed from and carry the spread as a separate field, so a synced balance is never quoted against a price it was not priced at.

SEBI cautioned that digital gold is unregulated — does that block the work?

No. SEBI's November 2025 caution describes the product's regulatory status, not a barrier to authorized data access. It shapes how we document provenance and consent for the gold ledger — recording who held custody and on what basis — rather than whether the data can be reached.

We have a consenting Jar account already — what else do you need?

The app name and what you want out of its data. Access, consent records and the compliance paperwork are arranged with you as the project runs; you do not assemble anything before we start.

How this was checked

Surfaces and figures were read from Jar's Play Store listing and the operator's own pages, cross-checked against India's Account Aggregator framework documentation and SEBI's November 2025 digital-gold notice. Reviewed 2026-06-26 by the OpenBanking Studio integration desk.

• Jar Play Store listing (com.jar.app)
• SEBI caution on dealing in digital gold (Nov 2025)
• Account Aggregator framework, Dept. of Financial Services
• SafeGold (Digital Gold India Pvt Ltd)