A central microchip portal could transform how lost pets get home. At its core, it's a simple idea: make it easy for the right people to find the right record, quickly and reliably, no matter which database holds it.
The current problem
Right now, 24 somewhat interconnected databases mean authorised users enter a chip number once to discover which database holds the record, then must login or phone individually for owner details. Inconsistent interfaces and processes create an "administrative burden" that delays reunions, as the British Veterinary Association confirms.
As Pet Theft Reform notes:
"The Stolen and Missing Pets Alliance (Sampa) started campaigning for pet microchipping reform in 2014, and Pet Theft Reform joined in 2018 calling for a single, centralised microchip database."
Current process vs central portal
Current flow (vet finds stray dog):
📱 Scan chip → 15-digit number
↓
🌐 Enter into chip-checker database portal
↓
🔍 "Found on Database X" [Primary result]
↓
🔐 Login to Database X (username/password setup required if not already setup)
⏱️ Wait for credentials email
🔑 Remember to securely store credentials
↓
📋 Retrieve owner details (may be incomplete or outdated)
↓
⚠️ "Also appears on Database Y – check for conflicts?"
↓
🔐 [If checking Y] Login to Database Y (separate credentials needed)
⏱️ Different UI, different process
↓
🔍 Compare information across both records
❓ Which database has the correct number?
❓ Which owner address is current?
❓ Has owner changed microchip provider?
↓
[Repeat for Databases Z, A, B... if needed]
↓
📞 Call owner(s) with best-guess contact details
⚠️ Phone number outdated? Email address wrong?
😞 Message goes to voicemail
⏰ Delays reunificationWith central portal:
📱 Scan chip → 15-digit number
↓
🌐 Enter into CENTRAL PORTAL (single login, one-time setup)
↓
⚡ Portal queries ALL 24 databases in parallel (<5 seconds)
↓
📋 Unified result with conflict resolution:
✅ Primary owner: John Smith, 07700..., john@email.com
⏰ Last verified: 2026-01-25
📌 Status: Missing since 2026-01-25
🔗 Cross-referenced across: Database X (primary), Y, Z
⚠️ Conflicts flagged: Address differs in Database Y (outdated)
↓
📞 Contact owner directly (verified current number)
✅ Single source of truth
✅ Immediate reunificationMaking it attractive for database companies
Database companies might hesitate, but a well-designed portal could simplify their lives while possibly opening new revenue:
Engineering simplicity: One published API spec replaces endless custom integrations for councils, vets and police. Teams focus on features, not compatibility.
Potential Revenue opportunities:
- Premium reunite alerts ("Your pet was just scanned 5 miles away")
- Data hygiene upsells ("Your details aren't in 3 databases – fix now for £9.99")
- White-label apps and enterprise licensing
- Analytics dashboards for vets/insurers ("92% reunite rate in your area")
- Stolen pet recovery insurance partnerships
- Microchip resale at point-of-registration
- Bulk scanning devices and hardware licensing
- Certification and training programs for scanning professionals
Easier life + more money: Who wouldn't want standardised integrations and premium services? Higher reunite success drives registrations (more chips = more revenue). They compete on service quality, not obscurity.
Regulatory carrot: Compliance becomes automatic via the portal, reducing scrutiny.
The technical foundation: standards that work
This isn't just "one website". It's API contracts, versioned schemas and interoperability standards, along with changing hearts and minds.
A Lookup API That Works
Here's what a proper chip lookup contract should do – one that databases publish, and the central portal calls:
Endpoint: GET /v1/microchips/{chipNumber}
What happens when a vet enters a chip number into the central portal:
The portal makes parallel requests to all 24 databases simultaneously:
[Central Portal]
↓
┌─────────────────────────────────────────┐
│ Querying all databases in parallel... │
├─────────────────────────────────────────┤
│ ✓ PetLog (responded: 45ms) │
│ ✓ Identichip (responded: 62ms) │
│ ✓ Petregistered (responded: 38ms) │
│ ✓ Homeagain (responded: 51ms) │
│ ... [20 more databases] │
│ ✓ All responses received (< 1 second) │
└─────────────────────────────────────────┘Each database responds with a structured format:
Request sent to each database:
GET /v1/microchips/985112345678901
Authorization: Bearer {api_key}Success Response (200 OK):
{
"success": true,
"data": {
"chipNumber": "985112345678901",
"chipType": "ISO 11784/11785",
"species": {
"code": "canis_familiaris",
"label": "Dog",
"breed": "Fox Red Labrador",
"colour": "Red",
"sex": "Female",
"petName": "Luna",
"kcRegName": "Jason Lucy Luna Hunter the 3rd",
"marks": "Scar on nose"
},
"status": "missing",
"registrationDate": "2020-03-15",
"lastScanDate": "2026-01-20T14:30:00Z",
"owner": {
"contactAvailable": true,
"notifyOnScan": true
},
"sourceDatabase": "PetLog",
"sourceRegion": "GB-ENG",
"backupDatabases": ["Identichip", "Petregistered", "Find-a-Pet"],
"metadata": {
"version": "v1",
"lastUpdated": "2026-01-26T14:30:00Z",
"verifiedAt": "2026-01-20T14:30:00Z"
}
}
}Not Found Response (404):
{
"success": false,
"error": {
"code": "CHIP_NOT_FOUND",
"message": "No record found for this chip number",
"suggestion": "Check chip number format and try again"
}
}What this could enable:
- The central portal calls all 24 databases in parallel, gets structured data back
- Status codes are standardised ("missing", "registered", "deceased") so the UI works everywhere
- Contact availability is flagged (owner wants alerts vs. privacy mode)
- Backup databases are listed, so conflicts are visible and resolvable
- Metadata shows when data was last verified (stale records are flagged)
- Error codes let the portal suggest fixes ("invalid format" vs. "not found")
Evolution happens safely: Future versions add new fields (reunite alerts, vet contact, insurance info) without breaking v1 consumers.
Interoperability maps "L" (Lost) and "M" (Missing) to the standard status: "missing". Different databases use different codes; the API normalises them.
Governance: Technical working group approves changes via public changelog. Database companies get 6 months to adopt v2 before v1 is deprecated.
Why hasn't this happened already?
- Commercial lock-in: Each database wants to be the database, not a participant.
- Coordination costs: 24 companies/databases negotiating standards would be incredibly painful, but not unachievable.
- Engineering debt: Legacy systems struggle with modern APIs.
- No clear owner: Government expects industry to solve it; industry expects government leadership.
A mandated standard could change all that. Companies get integration confidence, possible new revenue streams, and regulatory compliance – while government gets a working system.
Benefits across the chain
Owners: Faster reunions, better data hygiene. As Pet Theft Reform emphasises:
"Your microchip is the only way of linking your pet to you, if your details aren't correct, your pet may never make it home."
Professionals: One portal, audit trails, saves valuable time
Databases: Less engineering friction, premium services
Government: System-wide metrics
"Compulsory scanning [at a pet's first veterinary visit] would act as an extra deterrent to thieves at no extra cost, and of course help reunite stolen pets with their worried families." – Dr Marc Abraham OBE
Even MVP scope (chip lookup for approved users) could cut massive friction. When a scared dog sits in kennels and an owner refreshes their phone, turning 24 disconnected systems into one coherent flow isn't just technical. It's welfare.
As Dr Daniel Allen puts it:
"Pet Theft Reform is about family."
Next steps
I've started work on this with a Freedom of Information request to DEFRA – the first specific request about central microchip portal implementation that I could find.
Next, I'm sketching a basic technical outline:
- Published API specification (OpenAPI 3.1 format – the current industry standard with full JSON Schema support)
- Minimum viable data schema (chip, status, contact availability)
- Simple governance model for evolution
This isn't a complete solution – I'm just thinking out loud, from someone who spends their day managing software products and their spare time learning full-stack web engineering. I hate seeing solvable problems sit unsolved. Watch this space.