Pulling FreeClaim's open-settlement catalog into your own product

Every entry on FreeClaim's Browse screen is one open class-action settlement: a company, a short eligibility line, a hard filing deadline, and a link out to the official claim form on a settlement administrator's site. That list is server-side. The app refreshes it roughly weekly, adds cases as they are certified, and fires deadline reminders so a filing window does not pass unnoticed. For a budgeting app, a neobank, or a rewards product, that curated catalog is the asset worth integrating — not the on-device claim notes, but the live, deadline-stamped list of money consumers can claim right now.

The bottom line: there is a single high-value object here — the settlements catalog — and the route to it is a choice between fidelity and independence. Mirroring the feed FreeClaim's own client reads gives you the catalog exactly as the app curates it, deadlines and no-proof flags intact, in days. Sourcing the same upstream the app draws on — administrator portals and public court records — costs more to stand up but leaves you a catalog that owes nothing to FreeClaim's client. For a buyer who wants the list fast and faithful, the feed mirror is where we start; we layer direct sourcing in when long-term independence outweighs setup time.

What's inside the catalog

The app reads as a thin client over a settlements backend. Each row below maps to something a user actually sees in FreeClaim, and to what an integrator would do with it once it is normalized.

Getting the catalog out

Three routes genuinely apply to this app. They differ in what they reach, how long they last, and how much we set up.

Protocol analysis of the catalog feed

FreeClaim fetches its list from a backend over HTTPS; reading that traffic gives us the list request and the fields each settlement carries. Reach: the full catalog as the app curates it, including the no-proof flag and the deadline. Effort: low — days, not weeks. Durability: tied to the app's client, so we watch for shape changes on the weekly refresh. We arrange the capture environment and any test device with you at the start, then deliver a normalized feed that tracks the app one-to-one.

Direct sourcing from administrators and court records

The same settlements live upstream on administrator portals and in public court records — the sources FreeClaim itself draws on. Reach: everything the app has plus cases it has not picked up yet. Effort: higher, because each administrator (Kroll, Epiq, Angeion, JND) publishes differently. Durability: high — the result owes nothing to FreeClaim's client. We stand up per-source adapters and a deduplication pass so one settlement does not appear twice under two administrators.

Consented on-device export

Because claim tracking and reminders live on the device, a consenting user can export their saved cases and reminder schedule. Reach: narrow — per-user state only, not the catalog. Effort: low. Durability: fine, as long as the on-device format holds. This route matters only when a buyer wants to migrate a user's own claim history, and it runs with explicit user consent.

Given how this app is built — a curated list it refreshes weekly and a filing flow that hands off to administrators — the feed mirror does the most for the least, and we reach for direct sourcing only when a buyer needs the catalog to outlive changes to FreeClaim itself.

What lands in your repo

Each deliverable is tied to a real surface above, not a generic checklist.

• OpenAPI / Swagger spec for the normalized settlements feed: list, detail, deadline fields, the no-proof flag, the claim URL and its administrator.
• Protocol and auth-flow report covering how the app authenticates to its backend (an app-issued token over HTTPS, with no end-user login since there is no signup) and how the delta refresh behaves.
• Runnable source in Python and Node.js for the catalog pull, the normalization step, and the per-administrator link mapper.
• Automated tests: schema validation, deadline parsing across formats, claim-link resolution, and a freshness check against the weekly refresh.
• Interface documentation a developer can hand to a teammate.
• Compliance and retention guidance for the user-side claim data (name and email) under CCPA and CPRA, kept separate from the public catalog.

How the catalog pull looks

Illustrative shape of the list request and one settlement record. Field names and the host are confirmed during the build, not guessed here.

# Catalog pull — illustrative; exact host and field names confirmed during the build
GET /v1/settlements?status=open&market=US
Host: APP_BACKEND               # resolved from FreeClaim's own traffic
Authorization: Bearer APP_TOKEN # app-issued; there is no end-user login
If-Modified-Since: Mon, 09 Jun 2026 00:00:00 GMT   # delta refresh; 304 when unchanged

200 OK
{
  "refreshed_at": "2026-06-09T00:00:00Z",     # catalog updates roughly weekly
  "settlements": [
    {
      "id": "equifax-data-breach",
      "company": "Equifax",
      "case": "Equifax Data Breach Settlement",
      "eligibility": "US consumers affected by the 2017 breach",
      "proof_required": false,                 # the app's name-and-email-only flag
      "deadline": "2026-07-15",                # drives the 3-day-out and close-date alerts
      "claim_url": "https://.../file-a-claim", # outbound to the administrator's form
      "administrator": "JND Legal Administration"
    }
  ]
}

# Errors handled: 304 (skip), 401 (token refresh), 429 (backoff), partial-page schema drift
      

The shape we hand back

The normalized object is what your code reads — stable field names regardless of how the upstream phrases things.

// One row of the delivered feed
{
  "settlement_id":      "string",
  "company":            "string",
  "case_name":          "string",
  "eligibility_summary":"string",
  "no_proof_required":  true,
  "filing_deadline":    "ISO-8601 date",
  "official_claim_url": "string",
  "administrator":      "Kroll | Epiq | Angeion | JND | ...",
  "status":             "open | closing-soon | closed"
}
      

Where it plugs in

• A budgeting app shows "settlements you may qualify for" in its feed, each with a deadline badge sorted by how soon it closes.
• A neobank pushes new no-proof settlements to members as a perk, deep-linking the official claim form.
• A personal-finance newsletter auto-builds its monthly "claim these" roundup from the feed.
• A reminders or calendar product imports filing deadlines so a user never misses a close date.

Public records, personal data, and the line between

This is not an account-aggregation app, so no open-banking consent regime applies. The data splits cleanly. The catalog is settlement metadata from public court records and administrator notices — no personal information. Personal data appears only when a claimant types a name and email into a claim form, and that is squarely CCPA and CPRA territory.

On the public side, our posture follows the Ninth Circuit's hiQ v. LinkedIn ruling as summarized by the California Lawyers Association: collecting public data is not itself a computer-fraud violation, but a site's terms are enforceable by contract. So we work under the client's written authorization, honor each administrator's terms, log what we collect, and keep the integration to settlement metadata. On the personal side, we minimize, keep claim data on-device-first where the design allows, record consent, and sign an NDA where a buyer needs one. No personal claim data is ever folded into the public catalog feed.

What we handle on the build

Three things about this app shape the engineering, and we account for each as part of the work.

• Deadline correctness. Every settlement carries a hard close date, and the app fires reminders three days out and again on the day it closes. We model that cadence, normalize time zones, and handle claim-window edge cases so a downstream calendar never alerts late.
• Per-administrator link mapping. Outbound claim links point at several administrators, each with its own URL and claim-ID format. We map those patterns so deep-links keep landing on the correct official form when an administrator updates or moves a page.
• Catching the weekly drift. New cases land about once a week, and a refresh can quietly change a field or layout. We schedule a structural check against the expected shape so a change is caught before it reaches your data, rather than after it breaks the sync. Access to a test device and the capture environment is arranged with you during onboarding.

Screens we worked from

The app's own screenshots, used to map the Browse, Check, File and Track surfaces. Tap to enlarge.

Other apps in the same data space

These cluster into two data shapes a unified integration has to reconcile: catalog-only finders that publish the same open-settlement list, and account-linked scanners that hold per-user match and claim records behind a login. Names are listed for context, not ranking.

• Catch — links bank and card accounts to scan purchase history against active settlements, holding a per-user match list server-side.
• Settlemate — scans email and purchase history to match users to settlements and assists with filling out claim forms.
• Class Action Buddy — takes a user from a settlement to a filed claim inside the app, auto-filling and previewing the claim PDF.
• MoneyPilot — pairs subscription cancellation with class-action filing and keeps per-account spending insights.
• Sparrow — surfaces eligible settlements and files claims on a user's behalf.
• Claimed — tracks open settlements a user can join and the status of claims already filed.
• Payout — a settlements finder that catalogs open class actions and routes users to official claim forms.
• ClaimBee — lists class-action claims and walks users through filing each one.
• Claimly — aggregates open settlements and notifies users when a new eligible case appears.

Questions integrators ask

Can you reproduce FreeClaim's open-settlement catalog the way the app curates it, filing deadlines included?

Yes. We capture the list the Browse screen pulls from FreeClaim's backend — company, case, the eligibility line, the no-proof flag, and the deadline each entry carries — and return it as a normalized feed you can query. The reminder cadence the app uses, an alert three days out and again on the close date per its store listing, is preserved as structured fields so your own notifications fire on time.

The app files through Kroll, Epiq, Angeion and JND portals — do those official claim links survive in a feed?

They do. Each settlement points out to a claim form hosted by a settlement administrator, and every administrator uses its own URL and claim-ID format. We map those per-administrator link patterns so the outbound deep-link in your integration still lands on the correct official form when administrators rotate or update their pages.

Is the settlement data personal information we would have to manage under California privacy law?

The catalog itself is settlement metadata drawn from public court records and administrator notices, so it carries no personal data. Personal data only enters at the filing step, the name and email a claimant submits, and that is where CCPA and CPRA apply. We keep that data minimized, on-device-first where the design allows, and logged with consent, kept separate from the public catalog feed.

New settlements land in the catalog every week — how do you keep an integration from going stale?

We run the sync daily rather than on the app's weekly cadence, order entries by deadline proximity, and drop settlements once their filing window closes. A scheduled structural check compares the live feed against the expected shape, so a field or layout change on a refresh gets caught before it reaches your data. The first working build lands in one to two weeks.

Get it built

Source for the catalog feed — the OpenAPI spec, the normalized endpoints, automated tests, and interface docs — starts at $300 and is invoiced only after delivery, once you have confirmed it pulls what you need; or call our hosted endpoint and pay per call with nothing up front. Each build runs one to two weeks. Tell us the app name and what you want out of its data at /contact.html, and we handle access and compliance with you from there.

Sources and review

Checked on 2026-06-11 against the app's own store listings and the public settlement sources it draws on. The catalog behavior — roughly weekly refresh, name-and-email claims, the three-day and close-date reminders — comes from FreeClaim's App Store listing (iOS id 6760684773, per Apple's store). Administrator and claim-portal detail comes from Angeion Group's claims-administration pages and the open-settlement indexes at Top Class Actions. The public-data and terms-of-use reasoning follows the Ninth Circuit's hiQ v. LinkedIn ruling, as summarized by the California Lawyers Association. App identity confirmed on the Apple App Store listing.

Mapped by the OpenBanking Studio integration desk · reviewed 2026-06-11.