PetraPetra
For relocation, airlines, boarding, insurance

Accept verified pet records without chasing paperwork.

Petra lets your team verify pet health credentials instantly, without chasing PDFs, calling clinics, or manually checking expiration dates. Each credential is digitally signed by the issuing clinic and can be verified in a browser, inside your portal, or against Petra's public audit layer.

Owners arrive with their rabies certificate, USDA Form 7001, EU AHC, or vaccine record already proven. No fax. No PDF roulette. No same-day calls to the issuing clinic.

Verify a credential in your browser Talk to us
Who Petra works with

Replace paper provenance with signed provenance.

Most pet credential flows still depend on emailed PDFs, faxed certificates, and same-day calls to the issuing clinic. Petra credentials remove every one of those steps without changing the regulatory shape of the document. If you accept a printed Form 7001 today, you can accept the Petra-signed version tomorrow.

Pet relocation
Coordinate cross-border moves without the back-and-forth
Owners send a single Petra link. Your team sees every credential the destination requires, the audit trail behind each, and the validity window. Your team never has to call the issuing clinic to re-confirm.
Airlines
Counter check-in in seconds
Counter agents scan the printed QR or open the Petra wallet pass. The verifier renders the destination requirements alongside the credentials, with a green check or a red blocker. The same rules logic designed for cross-border verification.
Boarding + daycare
Intake without the vaccine paperwork trade
Owners share a vaccination credential link instead of digging up an old PDF. Required vaccines and their expiry are surfaced; expired credentials get flagged before the dog reaches your front desk.
Insurance
Underwrite from signed health records
A pet's vaccination history and confirmed credential issuance dates are tamper-evident. Use them in claims, underwriting, or post-loss verification. Issuance integrity is verifiable without contacting Petra.
A concrete example

Boarding intake, today. A pet arrives. Staff ask the owner for proof of rabies, DHPP, and Bordetella. The owner digs through email, finds three PDFs from different clinics, hands them over. The front desk reads the expiry dates by eye, flags one that looks recent enough but might be the wrong dose. The owner promises to call their vet. The dog waits in the lobby.

With Petra. The owner shares one link from their wallet. The verifier renders all three credentials, surfaces the expiry on each, and flags Bordetella as expired before the dog reaches the front desk. Staff time per intake drops from minutes to seconds, and the liability shifts from "we trusted a PDF" to "we verified a signed credential."

How verification works

Three steps, all in your environment.

Verification runs offline, in the verifier's browser, against a public key from Petra's issuer registry. Petra's app servers never assert the answer; the cryptography does.

1
Pull the credential
Scan the printed QR or open the wallet pass. The credential id resolves to a signed JWS over a W3C Verifiable Credential payload.
2
Verify the signature
Petra's issuer registry is at /.well-known/petra-issuers.json. Look up the issuer's P-256 public key by kid and verify the JWS locally with WebCrypto.
3
Cross-check the chain anchor
The same content hash is anchored on Base. Re-fetch AnchorLog.getAnchor(content_hash) from any Base RPC; it confirms the credential was issued at the recorded time and not since revoked.
Why it's safe to accept

Three independent trust layers, none of them us.

A credential does not require trusting Petra's database. Each layer is independently verifiable without our app servers being reachable.

Signature layer
ECDSA P-256 / SHA-256
Each clinic signs with its own KMS-managed key. The public key is published at /.well-known/petra-issuers.json alongside the issuer name and accreditation. W3C Verifiable Credentials Data Model.
Anchor layer
Base (public L2)
Content hash of every issued credential goes on chain. Revocations land in a sibling contract. The credential's issuance time and revocation status are auditable independently of Petra's database.
Holder layer
Apple Wallet + Google Wallet + portable bundle
Owners carry credentials in their device wallet OR download a self-verifying JSON bundle (JWS + cached issuer JWK + chain anchor + verify recipe). A credential survives Petra-the-company; an offline verifier with off-the-shelf JWS tooling can confirm it from the single file.
Integration paths

Use it tonight. Productionize when ready.

Three paths, sized by how much engineering you want to commit. Start at the top; move down as the integration matures.

Day-one
Scan the QR. A printed Petra credential or a wallet pass carries a QR pointing at https://petraverify.id/verify/{id}. Open it in any browser; the credential renders with its verdict in under three seconds. Counter agents can install petraverify.id/verify/scan to their home screen for camera-driven scans.
Light embed
Iframe or popout the verifier. Embed the public verifier inside your existing portal. No SDK, no auth flow; the verifier is fully self-contained. Useful when the counter agent already uses your software.
Native
Verifier integration kit (in development). A typed JS package wrapping the fetch + verify + anchor-check logic in three lines. Pull the verdict directly into your booking flow, audit log, or claim system. Available to partners who ask: partners@petraverify.id.
Next step

Let us walk you through a real credential.

Twenty minutes. We verify a real credential, show the printed packet, wallet pass, and audit trail, then map it to your check-in, relocation, boarding, or claims workflow. No deck.

Schedule a demo Open a live credential