Webhooks

Webhooks let InsideTracker notify your system when result processing, data onboarding, or generated content reaches a point your integration may need to act on.

Use webhooks for event-driven updates. Use status or retrieval APIs when your application needs the latest state on demand, or when it needs to recover after a missed event.

Where This Fits

Use this page when your integration needs to react to asynchronous InsideTracker updates instead of relying only on polling.

Event Types

The current public API reference documents these webhook events.

Data Processing And Platform Events

These events tell your system that blood result processing or data onboarding workflow state has changed.

Content And Output Availability Events

These events tell your system that a User-facing output or generated content is available or has been recalculated.

What To Do With Events

Before You Begin

To receive webhooks, provide InsideTracker with the endpoint URL where webhook events should be delivered.

Your webhook endpoint should:

• Accept HTTPS POST requests.
• Parse JSON request bodies.
• Return a success response quickly after receiving an event.
• Store the event or enqueue downstream work before doing slower processing.
• Use event identifiers to avoid duplicate downstream actions if the same event is replayed, resent, or manually retried.

Confirm endpoint configuration, authentication, and delivery behavior with InsideTracker before production launch. The public API reference documents event paths, payload schemas, examples, and the expected 200 response from your endpoint; integration-specific delivery settings may be configured outside the public API reference.

Payload Examples

{
  "extId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "bloodTestId": 99
}

{
  "extId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "bloodTestId": 99
}

{
  "extId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "bloodTestId": 99,
  "mbd": {
    "partnerId": "partner-xyz"
  }
}

{
  "timestamp": "2025-01-15T10:45:00Z",
  "processId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "extId": "6fa85f64-5717-4562-b3fc-2c963f66afa6",
  "status": "PUBLISHED",
  "autoPublishResult": true,
  "validationMode": "AUTO",
  "bloodResults": [
    {
      "legacyId": 99
    }
  ]
}

Handling Events

When your endpoint receives a webhook:

1. Validate the request according to your configured webhook security model.
2. Parse the JSON payload.
3. Use extId to find the matching User in your system.
4. Store the event or enqueue downstream work.
5. Return a success response quickly.
6. Process follow-up actions asynchronously.

Use event-specific identifiers for correlation:

Idempotency And Recovery

Design webhook processing so your system can safely receive the same logical event more than once.

Recommended practices:

• Store received events with a stable deduplication key.
• Use extId plus event type and event-specific identifiers such as bloodTestId or processId.
• Return a success response after safely storing or queuing the event.
• Retry downstream work from your own queue if your internal processing fails.
• Use status or retrieval APIs to recover state when your system may have missed an event.
• Log malformed events without exposing sensitive User data.

Testing Webhook Workflows

During sandbox testing, confirm that your webhook endpoint can:

• Receive events from InsideTracker.
• Match extId to the correct User.
• Handle each event type your integration subscribes to.
• Avoid duplicate downstream actions.
• Recover state through status or retrieval APIs when needed.
• Fail gracefully when downstream systems are unavailable.

The sandbox API includes an endpoint to emulate a User test result being published:

POST /enterprise/sandbox/sa/v1/customer/{externalId}/blood-test/{testId}/publishResult
Authorization: Bearer {service_access_token}

Use this as part of webhook and downstream workflow testing when validating blood-result-related event handling.

Related API Reference