Getting Started with the DepositScout API

DepositScout’s API turns the UK savings market into structured data you can query — live rates, historical movements, provider metadata and current-account switch offers — without scraping bank sites or maintaining brittle parsers.

This guide covers what you get today, who it’s for, how to request access, and what a first successful call looks like. For the marketing overview, see the API Access page.

What the API covers today

Four core products ship now. Each is a REST endpoint returning JSON:

• Live Savings Rates — GET /v1/rates — current AERs across Easy Access, Fixed Rate, Notice, Cash ISA and Regular Saver accounts, normalised for software.
• Historical Rates — GET /v1/history — how every product has moved over time for charts, benchmarking and analysis.
• Provider Directory — GET /v1/providers — bank and building society metadata, including FSCS coverage and eligibility signals.
• Current Account Switch Offers — GET /v1/switch-offers — live switching bonuses, deadlines, eligibility rules and linked saver products.

More feeds (mortgage rates, base-rate history and savings analytics) are on the roadmap; the same access conversation covers what you need now and what you’ll want next.

Who it’s built for

Teams use DepositScout when they need production-ready UK savings data rather than a one-off scrape:

• Fintech apps — recommendations, comparison tools and in-product savings experiences
• Banks & building societies — market benchmarking against peers
• Publishers — best-buy tables and articles that stay current
• AI products — structured, up-to-date market context for assistants
• Wealth platforms — better cash opportunities for clients
• Researchers — trend and rate-movement analysis over time

How access works

Access is commercial and licensed. There isn’t a public self-serve signup yet — you request access, we learn what you’re building, and we provision keys once commercial terms are agreed.

1. Tell us your use case on the API access form, or email [email protected].
2. Share roughly what endpoints you need, expected volume, and timeline.
3. We’ll reply with next steps on licensing and technical onboarding.
4. Once live, authenticate with a bearer token on every request.

Include enough detail that we can map you to the right feeds — for example “best-buy table for easy access + ISA, refreshed hourly” is far more useful than “need rates API”.

Your first request

After you have a key, a minimal live-rates call looks like this:

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

Responses are JSON. A simplified product object looks like:

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

Field names and nesting are designed for software: consistent provider names, account categories and structured attributes — not free-text scraped from marketing pages.

What “always monitoring” means in practice

DepositScout continuously tracks UK banks and building societies so product and rate changes land in the feed quickly. Historical rate moves are retained by default, so charts and analytics don’t depend on you having been collecting since day one.

That combination — live coverage plus history — is what most comparison, publishing and AI teams need to ship without standing up their own market-data stack.

Suggested integration path

1. Start with live rates — power a table, widget or ranking with /v1/rates.
2. Add history — use /v1/history for sparklines, “rate cut” badges or trend copy.
3. Enrich with providers — join FSCS and eligibility from /v1/providers.
4. Layer switch offers if your product also covers current accounts — /v1/switch-offers.

Keep API keys server-side. Don’t embed them in mobile apps or public frontends.

Next steps

If you’re evaluating the API for a product roadmap:

• Skim the product list on depositscout.com/api
• Send a short brief to [email protected] (or use the form)
• Mention which of the four feeds matter first, and whether history is required from day one

We’ll take it from there — from enquiry to a keyed environment you can build against.