Blood Result Upload
Submit blood result documents for asynchronous BRU processing, track status, and receive terminal updates when published results are available.
Blood Result Upload
Blood Result Upload, or BRU, lets you submit one or more blood result documents to InsideTracker for asynchronous processing. When processing publishes results, those results become structured biomarker data that can support recommendations, scores, Inner Age, and other User-facing experiences.
Start here for the shared BRU file upload, process submission, status, and webhook flow. Format-specific pages add source-preparation and User-experience guidance for each supported BRU path.
Send one supported blood result document at a time for a linked customer record.
Group uploaded files into an asynchronous BRU processing job.
Use webhooks or status polling to know when published blood results are available.
Where This Fits
Use BRU when a User already has blood result documents and your integration needs InsideTracker to process those documents in the background.
| You already have | You do here | This helps support |
|---|---|---|
| A linked InsideTracker customer record, a customer-level token, and one or more supported blood result documents | Upload each file, submit a BRU process, and track the process to a terminal state | Published blood results that can feed recommendations, scores, Inner Age, and other biomarker-based outputs |
BRU is different from lab ordering. Use Lab Connect when your integration needs to order a new Quest or Mobile Blood Draw test. Other blood result submission workflows are covered in their own guides.
What You Need
Before implementing BRU, make sure your integration has:
- A linked InsideTracker customer record for your User.
- A customer-level token obtained through the agreed on-behalf-of flow.
- One or more supported blood result document files.
- A way to store
uploadedFileIdandprocessIdvalues in your system. - A webhook endpoint for event-driven updates, or a polling job that can call the process status endpoint.
Workflow
BRU is asynchronous. Your application uploads files first, then submits a process that tells InsideTracker which uploaded files should be processed together.
- Collect or receive the User's blood result documents.
- Upload each document separately to the temporary BRU file endpoint.
- Store every returned
uploadedFileId. - Submit a BRU process with the full
uploadedFileIdslist. - Store the returned
processId. - Use the BRU terminal webhook or process status endpoint to track completion.
- When the process reaches
PUBLISHED, use the returned blood result identifiers in downstream blood result and output workflows.
API Flow
Step 1: Upload Each File
Upload each document separately:
POST /bru/customer/v1/files
Content-Type: multipart/form-data
Authorization: Bearer {customer_token}Include one required multipart field:
| Field | Type | Description |
|---|---|---|
file | string <binary> | Single PDF or image document file to process. Maximum size is 50 MB. |
Each successful upload returns 201 Created with an uploadedFileId.
{
"uploadedFileId": "97395c45-160a-44e6-a6db-f76570e12f8f"
}Store every returned uploadedFileId until you submit the BRU process.
File rules from the public API reference:
| Rule | Value |
|---|---|
| Supported file types | PDF and image documents |
| Supported MIME types | application/pdf, image/jpeg, image/png |
| Maximum file size | Smaller than 50 MB |
| Upload style | Upload each file separately |
| Rate limit | 14 files per customer per 300 seconds |
| File retention before process submission | Uploaded files expire after 24 hours if they are not submitted in a BRU process |
InsideTracker performs virus scanning on uploaded files. Infected files are rejected.
Common error responses are 400 for an invalid request, 401 for an unauthorized request, and 500 for an internal server error.
Step 2: Submit The BRU Process
Submit a process with the full list of file IDs returned by the upload step:
POST /bru/customer/v1/processes
Content-Type: application/json
Authorization: Bearer {customer_token}{
"uploadedFileIds": [
"497f6eca-6276-4993-bfeb-53cbbbba6f08"
]
}The process submission returns 202 Accepted with a processId and the current process state. Store the returned processId so your integration can correlate status responses and webhook events.
The response includes fields such as:
| Field | Description |
|---|---|
processId | Identifier for the asynchronous BRU process. |
autoPublishResult | Indicates whether the process is configured to publish results automatically. |
validationMode | Validation mode for the process, such as AUTO. |
status | Current process status, such as DOCUMENT_UPLOADED after submission. |
bloodResults | Published blood result legacy IDs when available. |
createdAt | Process creation timestamp. |
updatedAt | Most recent process update timestamp. |
Common error responses are 400 for an invalid request, 401 for an unauthorized request, and 500 for an internal server error.
Step 3: Track Processing
Use webhooks for event-driven updates when possible. If you need the latest process state, or if you need to recover after a missed webhook, poll the process endpoint:
GET /bru/customer/v1/processes/{processId}
Authorization: Bearer {customer_token}When a process is in a terminal state, the response may include bloodResults with published blood result legacy IDs.
Common status endpoint errors are 401 for an unauthorized request, 404 when the process is not found, and 500 for an internal server error.
Terminal States And Webhook Handling
The BRU terminal webhook is documented in the public API reference as:
POST /webhooks/bru-terminalUse the webhook payload to correlate the completed process back to the User and submission in your system.
| Field | Use |
|---|---|
extId | Maps the event back to your User. |
processId | Matches the event to the BRU process you submitted. |
status | Indicates the terminal process state. |
bloodResults | Contains published blood result legacy IDs when results are available. |
validationMode | Indicates the validation mode used for the process. |
autoPublishResult | Indicates whether the process was configured to publish automatically. |
Terminal states:
| Status | Meaning | Application action |
|---|---|---|
PUBLISHED | Processing completed successfully and published blood results are available through the existing Blood API. | Mark the submission complete and retrieve or refresh downstream blood result/output data. |
COMPLETE | Processing completed, but no published blood result was intentionally produced. This state is not expected for normal document-submission workflows. | Do not show new results. Route the submission through your support or exception-handling workflow. |
Example terminal webhook payload:
{
"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
}
]
}Implementation Checklist
Before building
- You have a linked customer record and customer-level token for the User.
- You accept only supported PDF, JPEG, or PNG source documents.
- You upload each file separately and store every returned
uploadedFileId. - You submit all relevant
uploadedFileIdsin one BRU process. - You store the returned
processId. - You can receive
POST /webhooks/bru-terminalevents or pollGET /bru/customer/v1/processes/{processId}. - You handle
PUBLISHEDas the success path for published blood results. - You have an exception path if processing completes without published results.
Related Topics
- OCR Blood Result Upload
- Webhooks
- Lab Connect
- Adding Profile Data
Updated 27 days ago