From Finshots' daily archive to a client your code can call

Ninety-five pages of archived daily explainers sit behind finshots.in/archive/, one new story most days, each one a tidy record with a slug, a headline, a dek, an author tag and a publish timestamp. That is the asset most people who ask about Finshots actually want: a clean, dated corpus of plain-English finance writing they can mirror, search, and re-surface inside their own product. The public site is a Ghost publication — the /archive/ paging and the /[slug]/ URLs give it away — which makes the content side unusually well-shaped for a typed client. The per-reader side (saved bookmarks, the notification time, light/dark choice) lives behind the app account, and reaching that is a separate, smaller job described below.

OpenFinance Lab builds the integration end to end. You give us the app name and what you need out of it; we work out the authorized route, write the client, and hand back code that runs against your own account or content store. The lead this page takes is SDK-first: a small Python or Node package your services import, not a pile of scraping scripts you have to babysit.

What sits behind the app and the archive

Finshots is two data surfaces wearing one brand. The editorial corpus is public and stable; the account state is private and per-user. We map both, and which ones matter depends on whether you are building a content feature or a reader-facing one.

Routes in

Three ways reach this data, and they are not equal. Here is what each gets you and what we set up to run it.

Authorized content mapping

The story corpus, its tags and author bylines come through the Ghost content surface and the archive's pagination. Reachable: the full dated history and the daily head. Effort is low to medium — most of the work is shaping pagination and parsing each story into fields. Durability is high; a Ghost archive structure rarely shifts under you. We map the endpoints, write the client, and set up the cursor so backfill and daily delta share one code path.

App protocol analysis under user consent

Bookmarks, the notification time and theme choice never appear on the public site. We reach them by observing the authenticated app traffic with a consenting account, then describing the request and token chain that returns them. Effort is medium; durability is medium, since these calls move with app releases, so we note the version we built against. Access here is arranged with you during onboarding and the build runs against a test account you control.

Native share as a fallback

The in-app share to WhatsApp, LinkedIn and X emits a canonical article URL. For light needs — a "send me this story" hook — that is enough on its own and costs almost nothing to wire. It does not scale to a full mirror.

For most briefs we make content mapping the backbone and layer protocol analysis on top only when the feature is reader-specific. If all you need is the daily corpus, the first route alone ships in days.

What lands in your repo

The headline deliverable is running code, not a binder.

• A Python and Node.js client for the content surface: list the archive, page through history, fetch a story by slug, filter by tag — each returning typed objects.
• A cursor-backed sync routine for backfill-then-daily-delta, with the stored position so a re-run resumes cleanly instead of re-walking the whole archive.
• A protocol & auth-flow report for the member surface — the token and request chain that returns a reader's bookmarks and notification time, written against a named app build.
• An automated test harness that asserts the parsed fields and the pagination behave, so a structural change shows up as a failed assertion rather than quietly bad data.
• An OpenAPI / auth-flow spec and interface documentation covering every surface we touched, plus data-retention and consent notes for the personal-data parts.

If you would rather not run any of it, the same surfaces are available as hosted endpoints you call — same data, none of the maintenance on your side.

A sketch against the feed

Roughly how the content client reads — fields confirmed during the build, this is illustrative:

from finshots_client import Archive

arc = Archive(base="https://finshots.in")

# daily delta: stop at the last slug we already stored
since = store.last_published()          # e.g. "2026-06-06T06:30:00+05:30"
for story in arc.iter_stories(after=since):
    # story -> typed record, not raw HTML
    store.upsert({
        "slug":      story.slug,         # "why-the-rupee-slid"
        "title":     story.title,
        "dek":       story.dek,
        "tags":      story.tags,         # ["Economy", "Markets"]
        "author":    story.author,
        "published": story.published,    # ISO 8601, IST
        "read_min":  story.read_minutes, # 4
        "body_md":   story.body_markdown,
    })

# one-time backfill walks every archive page once
arc.backfill(pages="all", into=store)   # ~95 pages, then idle

Pagination, retry on a slow page, and the IST timestamp handling are the parts that bite if hand-rolled; the client absorbs them.

One story shape

Whatever route a field comes from, it normalizes to a single record so downstream code never branches on source:

{
  "slug": "why-the-rupee-slid",
  "title": "Why the rupee slid",
  "dek": "A 3-minute read on the week's currency move",
  "tags": ["Economy", "Markets"],
  "author": "Finshots",
  "published": "2026-06-06T06:30:00+05:30",
  "read_minutes": 4,
  "canonical_url": "https://finshots.in/archive/why-the-rupee-slid/",
  "media": ["https://.../infographic-1.png"]
}

Consent & DPDP

Public editorial content is just that — public — and pulling the archive raises no personal-data question. The line gets crossed the moment a reader's bookmarks, account or notification settings enter scope. India's Digital Personal Data Protection Act 2023 is the operative regime there, and its lawful basis is consent: free, specific, informed and revocable, in the Act's own terms. The notified DPDP Rules set a compliance deadline of 13 May 2027, per the government's own publication of the timeline. We build the member-data parts under recorded consent from the account holder, keep every access logged, store the minimum the feature needs, and work under an NDA where the engagement calls for one. None of that paperwork is something you assemble before we start — it is part of how we run the project with you.

Engineering notes specific to Finshots

Two things about this app shape the build, and we handle both.

First, the archive timestamps are in IST with a daily, not hourly, rhythm. We anchor the sync cursor on the publish datetime rather than a page number, so a re-run on a day with no new story does nothing instead of re-ingesting the head — and a day with a late edit still gets picked up because the cursor compares timestamps, not positions.

Second, the member surface and the public surface drift apart over time: the app ships new versions, the site's Ghost theme stays put. We pin the protocol-analysis report to the exact app build we observed and keep the content client decoupled from it, so an app update can change the bookmark call without touching the part of your pipeline that mirrors the corpus. When a member call does shift, only that small report needs a refresh, and the test harness flags it.

App screens

The published Play Store screenshots, for reference to the surfaces named above:

How this came together

Checked in June 2026: the public archive and its pagination, the Play Store listing for the feature set and the package id com.finception.finshots.android, and the current standing of India's data-protection law. Per its Play Store listing the app reports 500K+ readers and a rating near 4.9 — figures we cite, not measure. Primary sources opened:

• finshots.in/archive/ — the dated story corpus, tags and pagination
• Google Play listing — feature set, package id, reported audience
• DPDP Act 2023 — brought into force — consent basis and the rules timeline

Engineering notes by the OpenFinance Lab integration desk, June 2026.

Nearby apps

Where Finshots sits in the Indian finance-content space, for anyone planning one ingestion layer across several sources:

• Moneycontrol — broad markets data, quotes and portfolio tracking alongside news; a deeper, structured-data counterpart.
• NDTV Profit (formerly BloombergQuint) — Bloomberg-sourced Indian and global markets coverage.
• The Economic Times — high-volume business and markets reporting with a large archive.
• Business Standard — corporate, economy and policy coverage with a long back-catalogue.
• Business Today — business magazine content spanning startups and SMEs.
• The Hindu BusinessLine — economy and markets commentary and analysis.
• The Morning Context — subscription long-form on business and tech, frequently named beside Finshots.
• CNBC-TV18 — market news and video, India-focused.
• Ditto Insurance — Finshots' sister product for insurance advice, account-based and WhatsApp-led.

Questions integrators ask

Can you keep a local mirror of the Finshots archive in sync as new stories publish?

Yes. The archive pages newest-first with one explainer published most days, so the client polls the front of the feed on a schedule and pulls anything whose publish timestamp is newer than the last cursor it stored. A first full backfill walks all the archive pages once; after that the daily delta is a handful of records. We hand you the cursor logic so a re-run picks up exactly where the last one stopped.

Does the daily archive arrive as structured fields, or just as page HTML?

Both are possible and we normalize to fields either way. Each story carries a slug, title, dek, author tag, publish datetime, read-time estimate and body. The client returns those as a typed object rather than a blob of markup, so you index or render without re-parsing HTML downstream.

How do you reach a member's saved bookmarks and notification time?

Those live behind the app account, not the public site, so we reach them by observing the authenticated app traffic with a consenting account arranged during onboarding. The bookmark list and the chosen delivery time map cleanly to per-user records the client can read back. Access is set up with you, and the build runs against a test account you control.

Which Indian rules govern pulling Finshots content and member data?

India's Digital Personal Data Protection Act 2023 is the operative regime for any personal data, with consent as the lawful basis and a compliance deadline of 13 May 2027 under the notified DPDP Rules. Public editorial content sits outside that, but the moment a member's bookmarks or settings are in scope we work under recorded consent, keep access logged and minimize what is stored.

Working with us

A first content client, with the cursor sync and tests, lands in one to two weeks; layering the member surface on top adds a little to that. Source code is delivered from $300 and you pay after delivery, once it runs against your own store or account; or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Tell us the app and what you want out of it at /contact.html and we will scope it back to you.