UK Savings Rates API for Publishers

If you run a money site, newsletter or comparison page, the hard part isn’t writing the table — it’s keeping it true. UK savings rates move often enough that yesterday’s “best easy access” can be wrong by lunchtime, and scraping provider sites is a full-time maintenance job.

A UK savings rates API solves that by giving you structured, queryable data for the products you already list: current AERs, categories, providers and (when you need it) history. DepositScout’s feed is built for that use case. Overview and access requests live on the API Access page.

What “best-buy ready” data actually needs

A publishable savings table usually needs more than a single percentage:

• Current AER for each product you show
• Account type — Easy Access, Fixed, Notice, Cash ISA, Regular Saver
• Provider name that matches how readers know the brand
• Context — is this rate new, fading, or stable? History helps you write that honestly
• Trust signals — FSCS protection and eligibility clues from a provider directory

DepositScout exposes those pieces as JSON over REST — live rates via GET /v1/rates, movements via GET /v1/history, and provider metadata via GET /v1/providers.

Why scraping falls apart for editorial teams

Bank marketing pages change layout without warning. Bonus terms hide in footnotes. The same provider appears under two trading names. Your CMS still needs a clean row: provider, product, AER, category, last checked.

An API doesn’t remove editorial judgement — you still choose which accounts to feature and how to explain caveats — but it removes the brittle fetch layer. You pull normalised fields on a schedule, then render your own table design and copy.

A practical publisher workflow

1. Pull live rates on a cadence that matches how often you publish (hourly for a live table; a few times a day for a morning roundup).
2. Filter to the categories you cover — many sites only need easy access + cash ISA on the homepage, with fixed bonds deeper in the site.
3. Use history before you shout “new market leader” — a one-day spike that already reversed isn’t a story; a rate that has held for a week might be.
4. Join provider metadata when you mention FSCS or eligibility, instead of copying boilerplate from a press release.
5. Cache server-side — never put an API key in the browser, and don’t hit the origin on every page view.

Example: what you query for a best-buy module

After access is provisioned, a live-rates call looks like:

curl https://api.depositscout.com/v1/rates \
  -H "Authorization: Bearer $DS_API_KEY"

You’ll get structured products you can map into your CMS or edge cache. A simplified object:

{
  "provider": "Zopa",
  "product": "Smart Saver",
  "category": "Easy Access",
  "aer": 4.42,
  "fscs_protected": true,
  "updated_at": "2026-07-07T09:00:00Z"
}

Pair that with /v1/history when your article needs a line like “this rate has held for X days” or a small sparkline beside the AER.

Switch offers if you cover current accounts too

Some publisher funnels mix savings tables with switching bonuses. DepositScout also ships GET /v1/switch-offers for live current-account switch deals — useful when your money section covers both “best saver” and “best switch” in the same hub.

Access and commercial use

This is licensed market data, not an open public dump. Request access with a short brief: which tables you run, how often you refresh, and whether you need history from day one. Use the form on /api or email [email protected].

If you’re still evaluating the whole product set, start with the getting-started guide: Getting started with the DepositScout API.