CDAS Credit Data Aggregation Service

One number in.
The whole picture out.

A person's credit standing is never in one place. Identity sits in one registry, outstanding debt in another, assessed income in a third — three systems, three APIs, three sets of rules about how long their answers stay good for. CDAS asks all of them and returns one record. Your application makes a single call and gets a complete picture.

Three registries, one callSources are queried in parallel and merged into one response. Add a fourth source and nothing on the calling side changes.
Cached to the secondEvery source states how long its data may be reused. Each is stored, and expired, on its own terms — never on a single blunt timer.
Honest under pressureIf a registry is unreachable you are told so, not handed a half-built record. Callers that need fresher data can demand it.
↓ Postman collection13 requests, with the cache behaviour asserted. Import by link: https://cdas.weget.cc/lookup-service.postman_collection.json
‹› The APIGET /credit-data/{ssn} and GET /ping — no key, no session, no request body.

How it works

One identifier in. Three lookups. One record out.

A request carries a social security number and, optionally, a caller's own caching terms. Each of the three data points is resolved independently — from local storage when that is still permitted, from the source when it is not — and only then merged into a single answer.

INPUT 424-11-9327 + Cache-Control (optional) personal-details private → default lifetime debt no directive → default assessed-income no directive → default PER SOURCE still fresh, and the caller accepts it? → serve from storage no network call otherwise → ask the source store it only if neither side said no-store any source missing → 404, never a partial OUTPUT one merged record 6 fields, 3 sources + Age · X-Cache

What comes back

Three requests, three records

The service answers about one person at a time — there is no endpoint that lists everybody. The table below is built by asking three separate times, once per person, and each row is that one request's complete answer assembled from all three sources.

Served from reports the whole record: HIT only when all three sources came from storage, and the age shown is that of the oldest part. A record can be mixed — one source fetched live while the other two are still valid in storage — which is what per-source caching looks like in practice.

Not loaded — this makes 3 requests
PersonRequestAddress Assessed incomeBalance of debtComplaintsServed from
No records loaded yet.

Live cache inspector

The cache is invisible. The street number isn't.

Caching is the part of this service you cannot see working — a correct cache and a broken one both return 200 OK. So this page makes it visible. The identity registry randomises the house number on every response it actually serves, which turns an invisible decision into something you can read: if two calls come back with the same number, the second one never left this server. If it changes, it did.

Every check below is that one comparison, run live against the real registries.

Idle
Request log0 requests
Waiting for a check to run.