Integrating with LITS is a thin adapter, not a rebuild. You keep your own product and database; you add a client that submits events to the registry and reads reference data back. Every vendor connects on the same open contract with its own key — no private agreement, no privileged access.
Authenticate per operator
Each integrated platform gets its own per-operator bearer key, so the registry attributes every submission to a known operator and can audit it. You pass the key on every call; the control-plane (admin) API is separate and you never call it.
The endpoints you use
| Method & path | Purpose | Returns |
|---|---|---|
| POST /v1/animals | Register or identify an animal | national_id |
| POST /v1/movements | Lodge a movement permit / consignment | permit_reference |
| POST /v1/vaccinations | Record a vaccination or disease event | id |
| POST /v1/certificates | Request a registry-signed certificate | reference, verify_url |
| GET /v1/zones?since_version=N | Pull veterinary/FMD zone reference data | delta of zones |
| GET /v1/verify/{token} | Public certificate verification (no auth) | sanitised status |
Write reliably
- Send an Idempotency-Key on every write so a retry never double-registers an animal or a permit.
- Retry with backoff behind a per-registry circuit breaker; the registry returns the original result for a repeated key.
- Read the acknowledgement ID on every write — national_id, permit_reference or id — and store it against your record.
- Sync zones by version: keep the last server_version and request only the delta since then.
Go from dry-run to live
- Build against the published OpenAPI contract using the sandbox and test keys.
- Run in dry-run: your adapter records what it would send, without making live calls, so you can verify mapping and volumes.
- Pass conformance: the public conformance suite checks your integration against the contract.
- Go live: receive a production per-operator key and flip the adapter from dry-run to live.
Stay forward-compatible
The contract is path-versioned (/v1). Additive, backward-compatible changes never break you — ignore the fields you do not consume. Breaking changes only ever ship under a new version, and every change is recorded in a public changelog you can follow.