Book blood tests from inside your own product

One API key gives you 45 endpoints, from booking to lab results

The Aniva Partner API books a blood draw at over 25 locations in Germany, adds panels to that appointment, and returns clinical and genetic results as JSON. Every request needs one header, and the base URL is the same in every environment.

When to use Aniva

Use Aniva when your customers needs a blood test booked
Use the appointment endpoints for a clinic draw and the home kit endpoints for a kit by post.
Use the results endpoints for clinical rows, genetic rows and the PDF report.
Use the catalog endpoints to read the biomarkers, panels and units Aniva sells.
Use the documented paths under https://anivahealth.com/api/v1/ and do not invent endpoints.
POST /api/v1/appointments
curl --request POST \
  --url https://anivahealth.com/api/v1/appointments \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "profile_id": "a3f1c2d4-8b7e-4f2a-9c1d-2e3f4a5b6c7d",
    "location_id": "b7e2d1f5-3c4a-4e8b-a2f1-9d0c1e2f3a4b",
    "scheduled_at": "2026-05-15T12:30:00+02:00"
  }'
The basic flow is four requests
GET /locations POST /profiles POST /appointments POST /appointments/{id}/confirm
45

45 endpoints are documented and live today

1

Authentication needs only one request header

v1

Every path starts with the v1 prefix

25+

German locations can do the blood draw

Four requests build a working integration

Four requests go from booking to lab results

Each request returns the ID the next one needs, so a basic integration is four requests before you add panels, reschedules or couriers.

Step 01 · GET /locations

You list the locations your key can book

The response gives you each address, the opening hours and the timezone, so a customer only sees slots that exist.

Tests
Step 02 · POST /profiles

You create a profile for the customer

A profile needs a name, a sex code, a date of birth and your profile_group, which accepts a UUID or your own slug.

Tests
Step 03 · POST /appointments

You book the appointment at a chosen slot

The booking needs the profile ID, the location ID and an ISO 8601 datetime with its offset or the Z suffix.

Tests
Step 04 · POST /appointments/{id}/confirm

You confirm the draw with the kit barcode

This request starts the lab order and locks the appointment, so change every panel before you send it.

Tests
POST /api/v1/appointments
curl --request POST \
  --url https://anivahealth.com/api/v1/appointments \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "profile_id": "a3f1c2d4-8b7e-4f2a-9c1d-2e3f4a5b6c7d",
    "location_id": "b7e2d1f5-3c4a-4e8b-a2f1-9d0c1e2f3a4b",
    "scheduled_at": "2026-05-15T12:30:00+02:00"
  }'
Capability

Every resource group is one REST collection

You can order a blood draw at a clinic, or a home kit by post. Both come back in the same format, so you only write the code that reads results once.

Profiles · 4 endpoints

A profile is the person you test

You look a profile up by email, create it under your profile group, and patch demographics later.

Tests
GET /profiles
PATCH /profiles/{id}
Appointments · 15 endpoints

An appointment has the panels and the draw

Fifteen endpoints cover the booking and every later change to it, including panels, container previews and the confirmation.

Tests
POST /appointments
GET /appointments/{id}/results
Home kit orders · 10 endpoints

Home kit orders are the mail version

Ten endpoints request a DIY kit for a profile, change its panels, and return the same result shape.

Tests
Create a kit order
Get results
Locations · 2 endpoints

Locations tell you where a draw happens

You read the locations your key can book, then ask one of them for its bookable slot starts.

Tests
GET /locations
GET /locations/{id}/availability
Documents · 1 endpoint

Results come back as clinical and genetic rows

Each order type has its own results call, and the PDF report is one separate download by file ID.

Tests
GET /appointments/{id}/results
GET /documents/{id}
Shipments · 8 endpoints

A courier takes the sample to the laboratory

You create a courier order with a weekday pickup window, then attach appointments and read its status updates.

Tests
POST /shipments
Attach appointments
Catalogs · 4 endpoints

Catalogs list the biomarkers you can order

The biomarker, panel and unit catalogs are paginated, and you can filter biomarkers by test location.

Tests
GET /biomarkers
GET /panels
Health · 1 endpoint

One readiness endpoint needs no API key

The readiness probe needs no API key, so your uptime monitor can call it on a schedule.

Tests
Public readiness probe
Your work ends at the barcode confirmation

The lab pipeline starts when you confirm the draw

You send us the kit barcode, and that is the last thing we need from you. We then organise the containers, the courier and the laboratory, so your code only calls two endpoints until the report is ready.

The Aniva lab pipeline from confirmation to results Confirming the draw is followed by container selection, courier collection and laboratory analysis, and each biomarker row then reads as planned, received or fault. POST /appointments/{id}/confirmYou confirm the draw GET /appointments/{id}/previewContainers are known POST /shipmentsA courier collects it Aniva laboratory networkThe laboratory analyses planned received fault GET /appointments/{id}/results
A filled dot is the route you want.A ring is a state you still handle.Orange lines are the confirmed order.
One parser reads a clinic draw and a home kit

Every result has two reference ranges and four statuses

Each clinical row has the range the laboratory reported and the Aniva range with its optimal window, so you can render both without keeping your own lookup table.

A row reads planned before the laboratory analyses it.
A row reads received once a value and a unit come back.
A row reads fault when the laboratory cancelled the request, and status_reason explains it.
GET /api/v1/appointments/{id}/results
{
  "status": "in_progress",
  "clinical_results": [{
    "status": "received",
    "biomarker_name": "Vitamin D",
    "value": 38.5, "unit": "ng/mL",
    "reference_range_lab": { "normal_min": 30, "normal_max": 100 },
    "reference_range_aniva": { "optimal_min": 40, "optimal_max": 60 },
    "tested_at": "2026-04-05"
  }],
  "documents": [{ "file_name": "lab-report-2026-04-05.pdf" }]
}
The API uses three time formats

Datetimes need a timezone or the request fails

A naive datetime is rejected with 400, which is the single mistake most first integrations make.

Timestamps always come back as UTC, using ISO 8601 with the Z suffix.
Inputs must include an explicit offset, so a booking accepts 2026-05-15T12:30:00+02:00.
Shipment updates keep the offset the logistics provider reported.
Calendar fields are wall clock only, such as a date of birth.
Aniva issues and rotates every partner key

Every request needs your partner API key

Authentication uses the x-api-key header on every call, and a missing or rotated key returns 403 with a short JSON error.

Your key decides which locations, appointments and shipments you can see.
Never expose your API key in client-side code or public repositories.
A public probe needs no API key

You can watch every service on the status page

The status page shows the current state and 90 days of history for each service, and the same data is available as JSON for your own monitor.

Partner keys are issued by our team

Ask us for a partner key today

Tell us which markets you sell in and which panels you need, and we will send a key with the right permissions.

You can also download the OpenAPI file

This page is a design mockup. Every endpoint and payload on it is taken from docs.anivahealth.com, and the pipeline diagram is illustrative.

Machine readable copies of the documentation are at docs.anivahealth.com/llms.txt and docs.anivahealth.com/llms-full.txt.