Test numbers

Every reserved MSISDN this sandbox answers for, and what each one returns on both endpoints. The same number always returns the same response, so you can build and test against these without coordinating with us.

These identities are fictional. Any number outside this list returns NOT_FOUND from lookup and a zero score from match-score — which is also the most likely real-world outcome, since the operator base does not cover the whole population.

A dash under match-score means the fixture holds no score data, so the endpoint answers as it would for an unknown number. The match-score column shows score · tier, where tier 1 is strongest and 3 weakest.

MSISDNLookupMatch scoreWhy it exists
242000000101FOUND96 · tier 1Recent SIM, exact match, stable behaviour
Reference scenario 1. The happy path. Pairs with 242000000202 — identical score and tier, stronger enrolment.
242000000202FOUND96 · tier 1Five-year-old SIM, equally exact match — LEGACY_KYC
Reference scenario 2. Same confidence as 242000000101, weaker original enrolment. The distinction Agoratech specifically asked for.
242000000203NOT_FOUND0 · tier 2Same-day SIM — record pending sync
Reference scenario 3. The daily SFTP batch means data is D-1 at best; same-day registrations are absent by design. Tier 2, not 3 — absence of evidence, not an anomaly (resolution 2).
242000000204NOT_FOUND0 · tier 2Genuinely absent from the base
Distinct from PENDING_SYNC (resolution 2). Expect a large share of live traffic here — see the not-found-rate open question.
242000000205FOUND68 · tier 2Name inversion — partial match, mid score
Send the claims in either order and the composite key resolves the same; name_inversion_detected reports that it happened. Claims-sensitive — see 05-scenario-engine.md section 3.
242000000206FOUND41 · tier 2DOB mismatch — low score
Names match, date of birth does not. Claims-sensitive: send the expectedIdentity dob and the score recovers.
242000000207FOUND22 · tier 3Shared universal ID, high device sharing — tier 3 anomaly
Tier 3 is reserved for observed anomalies (resolution 2). This is one.
242000000208FOUND57 · tier 2Declared district conflicts with estimated residence
Only reachable when identity_claims.declared_district is supplied. Omit it and nighttime_residency_tower_match must come back null, never false.
242000000209FOUND72 · tier 2Diaspora shape — location block null, score reduced
A local number on prolonged roaming: weak mobility, no nighttime residency tower. Kamoa's own open item — full coverage unvalidated.
242000000210FOUND8 · tier 3Large shared-ID cluster — top of the risk curve
Not in the published fixture list; added deliberately. Cluster above 50 lines correlates with a 77.4% default rate in the analysis. If one response should stop a reviewer, it is this one.
242000000211PARTIALPARTIAL — record found, mandatory attributes missing
PARTIAL — record found, dateOfBirth and ID document absent. Akieni's section 4.2 marks 8 of 11 fields required while their 4.3 defines PARTIAL as a missing mandatory attribute; both cannot hold. This fixture is the proof, and the one that makes them handle nulls.
242000000212FOUNDAirtel record — exercises the operator enum
Exercises Akieni's operator enum. NO AIRTEL DATA EXISTS BEHIND THIS — Airtel integration is unfinished upstream and its name fields may be encrypted differently. Say so in the handover; their section 1 assumes we already aggregate both.
242000000429HTTP 429 RATE_LIMITEDHTTP 429 RATE_LIMITEDForced 429 — rate limited
Akieni's section 4.3 specifies a 429 behaviour (one retry with backoff, then fallback). The real rate limiter is fast-follow, so without this fixture they cannot test a path they have already written.
242000000500HTTP 500 INTERNAL_ERRORHTTP 500 INTERNAL_ERRORForced 500 — error-path test
Never leak internals into error_message.
242000000503HTTP 503 UPSTREAM_UNAVAILABLEHTTP 503 UPSTREAM_UNAVAILABLEForced 503 — upstream unavailable
Not in the published fixture list; added deliberately. It is in the error catalogue, so it must be triggerable.
242000000504no response for ~30sno response for ~30sSlow response past the partner timeout
The point is to NOT respond, long enough that Agoratech's own client timeout fires and their fallback runs. Keep delayMs under the ALB idle timeout so the ALB does not close the connection first and produce a different failure than the one intended.

Next

API reference — the full contract, with request and response schemas.
openapi.json — import into your own tooling.
Postman collection, and an environment per stage.