# Generate token Source: https://docs.byblend.com/api-reference/authentication/generate-token /openapi-public.yml post /api/v1/auth/login Login to generate Blend API access tokens. Returns a JWT access token and refresh token. The access token expires in 60 minutes, and the refresh token expires in 7 days. # Refresh access token Source: https://docs.byblend.com/api-reference/authentication/refresh-access-token /openapi-public.yml post /api/v1/auth/refresh Refresh the access token using the refresh token. Note that this endpoint requires the refresh token (not access token) be sent in the Authorization header. Returns a new JWT access token. # Verify access token Source: https://docs.byblend.com/api-reference/authentication/verify-access-token /openapi-public.yml get /api/v1/auth/verify Verify the access token. Returns the user details. # Single request creation of a prescription and order (and patient/prescriber) Source: https://docs.byblend.com/api-reference/composite-creation/single-request-creation-of-a-prescription-and-order-and-patientprescriber /openapi-public.yml post /api/v1/prescriptions/electronic_prescriptions/composite The composite request is a convenience function that allows you to create an electronic prescription and order in a single request, and optionally also create a patient and/or prescriber. The request body can contain the following objects: `patient`, `prescriber`, `electronic_prescription`, `order`. While no single entity is required (the composite request can be used to create a standalone order or electronic prescription), it is designed to be comprehensive. If any single entity creation fails, the entire request will fail and no entities will be created. # Create a new electronic prescription Source: https://docs.byblend.com/api-reference/electronic-prescriptions/create-a-new-electronic-prescription /openapi-public.yml post /api/v1/prescriptions/electronic_prescriptions Deliver an electronic prescription to Blend either in SCRIPT XML or JSON. # Get electronic prescription Source: https://docs.byblend.com/api-reference/electronic-prescriptions/get-electronic-prescription /openapi-public.yml get /api/v1/prescriptions/electronic_prescriptions/{electronic_prescription_id} Retrieve an electronic prescription by ID. Electronic prescriptions may contain multiple medications. # Get quantity units Source: https://docs.byblend.com/api-reference/electronic-prescriptions/get-quantity-units /openapi-public.yml get /api/v1/prescriptions/quantity_units Retrieve the quantity units of measure for use in submitting electronic prescriptions. # Get an entity's exceptions Source: https://docs.byblend.com/api-reference/exceptions/get-an-entitys-exceptions /openapi-public.yml get /api/v1/exceptions/entity/{entity_type}/{entity_id} Retrieve the exceptions on an order or prescription. For an order, this includes exceptions on the order's prescriptions. The `order.stuck` webhook's `entity_type` and `id` map directly onto this path, including for a stuck prescription that is not yet on an order. # Get an exception Source: https://docs.byblend.com/api-reference/exceptions/get-an-exception /openapi-public.yml get /api/v1/exceptions/{exception_id} Retrieve a single exception on a stuck order or prescription. Use the `exception_id` from the `order.stuck` webhook. # Respond to an exception Source: https://docs.byblend.com/api-reference/exceptions/respond-to-an-exception /openapi-public.yml post /api/v1/exceptions/{exception_id}/responses Reply to Blend on a stuck order or prescription. The response is added to the exception's discussion and returns the exception to the Blend pharmacy team's queue. Responding does not resolve the exception; it clears once Blend resolves it or the missing data arrives. Blend's replies are sent to you with the `order.stuck_response` webhook. Include the first and last name of the person responding. For regulatory purposes, Blend must identify and keep a record of the authorized person behind every response. # Create a new webhook subscription Source: https://docs.byblend.com/api-reference/notifications/create-a-new-webhook-subscription /openapi-public.yml post /api/v1/notifications/webhooks Create a new webhook subscription for the current user. Your endpoint must be a valid SSL endpoint that accepts POST requests; returns a 2xx status code within 10 seconds; handles retries with exponential backoff. You may send a sample of any webhook to your endpoint using the `/notification/sample` endpoint. # Deactivate email subscriptions Source: https://docs.byblend.com/api-reference/notifications/deactivate-email-subscriptions /openapi-public.yml delete /api/v1/notifications/email Deactivate all email subscriptions for the current user. # Delete a webhook subscription Source: https://docs.byblend.com/api-reference/notifications/delete-a-webhook-subscription /openapi-public.yml delete /api/v1/notifications/webhooks/{webhook_id} Delete a webhook subscription by its unique ID. # DEP: Create a new subscription Source: https://docs.byblend.com/api-reference/notifications/dep:-create-a-new-subscription /openapi-public.yml post /api/v1/notifications Create a new subscription for notification events. This endpoint is deprecated. Please use the specific endpoints instead for webhooks or email. # DEP: Deactivate a subscription Source: https://docs.byblend.com/api-reference/notifications/dep:-deactivate-a-subscription /openapi-public.yml delete /api/v1/notifications/{subscription_id} Deactivate a subscription by its unique ID. This endpoint is deprecated. Please use the specific endpoints instead for webhooks or email. # DEP: Get subscriptions Source: https://docs.byblend.com/api-reference/notifications/dep:-get-subscriptions /openapi-public.yml get /api/v1/notifications Retrieve current endpoints and their subscriptions. This endpoint is deprecated. Please use the specific endpoints instead for webhooks or email. # Generate a webhook secret Source: https://docs.byblend.com/api-reference/notifications/generate-a-webhook-secret /openapi-public.yml post /api/v1/notifications/webhook-secret Generates an authentication secret for webhook endpoints. This secret will be sent as the `Authorization: Bearer {secret}` header in all webhook deliveries, allowing you to verify webhook events as originating from Blend. # Get a webhook subscription Source: https://docs.byblend.com/api-reference/notifications/get-a-webhook-subscription /openapi-public.yml get /api/v1/notifications/webhooks/{webhook_id} Get a webhook subscription by its unique ID. # Get email subscriptions Source: https://docs.byblend.com/api-reference/notifications/get-email-subscriptions /openapi-public.yml get /api/v1/notifications/email Get email subscriptions for the current user. # Get notification event types Source: https://docs.byblend.com/api-reference/notifications/get-notification-event-types /openapi-public.yml get /api/v1/notifications/events Lists available notification events and their descriptions. "All" is a special event that will trigger receipt for all events. # Get webhook subscriptions Source: https://docs.byblend.com/api-reference/notifications/get-webhook-subscriptions /openapi-public.yml get /api/v1/notifications/webhooks Get webhook subscriptions for the current user. # Preview a sample webhook payload Source: https://docs.byblend.com/api-reference/notifications/preview-a-sample-webhook-payload /openapi-public.yml get /api/v1/notifications/sample/{event_code} Get a sample webhook payload for a given event code. Data in this example is illustrative only. # Send a sample webhook Source: https://docs.byblend.com/api-reference/notifications/send-a-sample-webhook /openapi-public.yml post /api/v1/notifications/sample Send a sample webhook for testing integrations. This will include the webhook secret in the `Authorization` header if a secret has been set. Data in this example is illustrative only. # Update email subscriptions Source: https://docs.byblend.com/api-reference/notifications/update-email-subscriptions /openapi-public.yml put /api/v1/notifications/email Update email subscriptions for the current user. Email subscriptions will be delivered to the email specified in the user profile. # Update webhook subscriptions Source: https://docs.byblend.com/api-reference/notifications/update-webhook-subscriptions /openapi-public.yml put /api/v1/notifications/webhooks/{webhook_id} Update a webhook subscription. # Add products to an order Source: https://docs.byblend.com/api-reference/orders/add-products-to-an-order /openapi-public.yml post /api/v1/orders/{order_id}/products Add prescription products, non-prescription products, and/or order materials to an existing order. Edits are allowed when an order is in `received` status. Product references use the same `id`, `sku`, and (for prescription products) `product_code` rules as order creation. # Cancel an order Source: https://docs.byblend.com/api-reference/orders/cancel-an-order /openapi-public.yml put /api/v1/orders/{order_id}/cancel Cancel an order. Only orders in `received`, `paused`, or `exception` status can be cancelled. For orders already in `picked` or `verified` status, use Request Cancellation. # Create a custom compounding reason Source: https://docs.byblend.com/api-reference/orders/create-a-custom-compounding-reason /openapi-public.yml post /api/v1/reasons Add a new compounding reason to the Blend inventory. # Create an order Source: https://docs.byblend.com/api-reference/orders/create-an-order /openapi-public.yml post /api/v1/orders Create a new order. If a mergeable order exists for the provided patient, a new order request will be merged into the existing order, unless `force_new=true` is specified. Please see Order Merging for more details. # Get an order's details Source: https://docs.byblend.com/api-reference/orders/get-an-orders-details /openapi-public.yml get /api/v1/orders/{order_id} Retrieve details for a specific order by its unique ID. # Get an order's status history Source: https://docs.byblend.com/api-reference/orders/get-an-orders-status-history /openapi-public.yml get /api/v1/orders/{order_id}/status_history Retrieve the status history for an order. # Get compounding reasons Source: https://docs.byblend.com/api-reference/orders/get-compounding-reasons /openapi-public.yml get /api/v1/reasons Retrieve all compounding reasons. # Get order statuses Source: https://docs.byblend.com/api-reference/orders/get-order-statuses /openapi-public.yml get /api/v1/orders/statuses Retrieve all available order status codes and names. # Get orders Source: https://docs.byblend.com/api-reference/orders/get-orders /openapi-public.yml get /api/v1/orders Retrieve all orders. This endpoint returns paginated responses. Details on pagination are returned in response headers. - `X-Total-Count`: total number of items available - `X-Page`: current page number - `X-Page-Size`: number of items per page - `X-Total-Pages`: total number of pages available - `X-Remaining-Count`: number of items remaining after the current page # Get shipping options Source: https://docs.byblend.com/api-reference/orders/get-shipping-options /openapi-public.yml get /api/v1/orders/shipping_options Retrieve all available shipping carriers and service levels, to be used in an order's `shipping` object. # Pause an order Source: https://docs.byblend.com/api-reference/orders/pause-an-order /openapi-public.yml put /api/v1/orders/{order_id}/pause Pauses an order indefinitely (until it is manually unpaused). Only orders in `received` or `exception` status can be paused. For a timed pause, use Pause an Order Until a Date. # Pause an order until a date Source: https://docs.byblend.com/api-reference/orders/pause-an-order-until-a-date /openapi-public.yml put /api/v1/orders/{order_id}/pause/{date} Pause an order until the given calendar day. The order will automatically unpause when this date is reached. Only orders in `received` or `exception` status can be paused; calling again while already `paused` updates `paused_until`. # Prioritize an order Source: https://docs.byblend.com/api-reference/orders/prioritize-an-order /openapi-public.yml put /api/v1/orders/{order_id}/request_priority Request an order be prioritized in the queue. Blend will attempt to expedite filling of priority orders if they have not already been filled. # Remove a product from an order Source: https://docs.byblend.com/api-reference/orders/remove-a-product-from-an-order /openapi-public.yml delete /api/v1/orders/{order_id}/products/{product_type}/{id} Remove a single prescription product, non-prescription product, or order material item from an order. Edits are allowed when an order is in `received` status. # Replace an order Source: https://docs.byblend.com/api-reference/orders/replace-an-order /openapi-public.yml put /api/v1/orders/{order_id}/request_replacement Request a replacement for an order. # Request cancellation of an order Source: https://docs.byblend.com/api-reference/orders/request-cancellation-of-an-order /openapi-public.yml put /api/v1/orders/{order_id}/request_cancellation Request cancellation for an order already in process. This does not change order status. Only one request per order is allowed. # Unpause an order Source: https://docs.byblend.com/api-reference/orders/unpause-an-order /openapi-public.yml put /api/v1/orders/{order_id}/unpause Unpause an order, restoring the prior status and clearing `paused_until`. Only orders in `paused` status can be unpaused. # Update a custom compounding reason Source: https://docs.byblend.com/api-reference/orders/update-a-custom-compounding-reason /openapi-public.yml put /api/v1/reasons/{reason_id} Update the details for a specific compounding reason by its unique ID. # Update an order Source: https://docs.byblend.com/api-reference/orders/update-an-order /openapi-public.yml patch /api/v1/orders/{order_id} Partial update — send only the fields to change. `PUT` is also accepted with identical merge semantics for backward compatibility. Only address, external ID, (and, if supported in your account) custom shipping or shipping preferences (`carrier`, `service_level`, `signature_confirmation`) can be updated. Shipping details can only be updated if in certain statuses. (Orders that are `verified` are already in the shipping process, and those `shipped` or `delivered` are completed.) By passing `update_patient=true`, the address will also update the patient's address in the same request. Otherwise only the order's address will be updated. # Update order item quantity Source: https://docs.byblend.com/api-reference/orders/update-order-item-quantity /openapi-public.yml patch /api/v1/orders/{order_id}/products/{product_type}/{id} Update the ordered quantity for a single item on an order. Edits are allowed while an order is in `received` status. # Add freeform risk factor text Source: https://docs.byblend.com/api-reference/patients/add-freeform-risk-factor-text /openapi-public.yml post /api/v1/patients/{patient_id}/risk_factors/raw_text Attach unprocessed raw text risk factors to a patient. Text will be processed and parsed asynchronously. # Create a patient Source: https://docs.byblend.com/api-reference/patients/create-a-patient /openapi-public.yml post /api/v1/patients Create a new patient. Returns **400** with `existing_patient_id` (and, if populated, `existing_patient_external_id`) when the create attempt is identified as a duplicate of an active patient. # Deactivate a risk factor Source: https://docs.byblend.com/api-reference/patients/deactivate-a-risk-factor /openapi-public.yml delete /api/v1/patients/{patient_id}/risk_factors/{risk_factor_id} Deactivate a risk factor match for a patient. # Get a patient's details Source: https://docs.byblend.com/api-reference/patients/get-a-patients-details /openapi-public.yml get /api/v1/patients/{patient_id} Retrieve details for a specific patient by their unique ID. # Get a patient's orders Source: https://docs.byblend.com/api-reference/patients/get-a-patients-orders /openapi-public.yml get /api/v1/patients/{patient_id}/orders Retrieve all orders for a specific patient. # Get a patient's prescriptions Source: https://docs.byblend.com/api-reference/patients/get-a-patients-prescriptions /openapi-public.yml get /api/v1/patients/{patient_id}/prescriptions Retrieve all prescriptions for a specific patient. # Get a patient's risk factors Source: https://docs.byblend.com/api-reference/patients/get-a-patients-risk-factors /openapi-public.yml get /api/v1/patients/{patient_id}/risk_factors Retrieve all risk factors, or risk factors of a specific type, for a patient. # Get guardian relationship types Source: https://docs.byblend.com/api-reference/patients/get-guardian-relationship-types /openapi-public.yml get /api/v1/patients/guardian_relationship_types Retrieve a list of all available guardian relationship types. # Get patients Source: https://docs.byblend.com/api-reference/patients/get-patients /openapi-public.yml get /api/v1/patients Retrieve all patients. This endpoint returns paginated responses. Details on pagination are returned in response headers. - `X-Total-Count`: total number of items available - `X-Page`: current page number - `X-Page-Size`: number of items per page - `X-Total-Pages`: total number of pages available - `X-Remaining-Count`: number of items remaining after the current page # Update a patient's details Source: https://docs.byblend.com/api-reference/patients/update-a-patients-details /openapi-public.yml patch /api/v1/patients/{patient_id} Partial update — send only the fields to change. `PUT` is also accepted with identical merge semantics for backward compatibility. # Create a license/qualification Source: https://docs.byblend.com/api-reference/prescribers/create-a-licensequalification /openapi-public.yml post /api/v1/prescribers/{prescriber_id}/qualifications Create a qualification or license for a prescriber. # Create a new prescriber Source: https://docs.byblend.com/api-reference/prescribers/create-a-new-prescriber /openapi-public.yml post /api/v1/prescribers Create a new prescriber. If you attempt to create a preexisting prescriber (as determined by NPI), the existing prescriber will be returned. If the prescriber already exists elsewhere in Blend (as determined by NPI), the existing prescriber will be associated with your customer. # Create a supervisorial relationship Source: https://docs.byblend.com/api-reference/prescribers/create-a-supervisorial-relationship /openapi-public.yml post /api/v1/prescribers/{prescriber_id}/supervisors Create a supervisorial relationship for a specific prescriber in a specific state. Supervisors must have a valid qualification in any state to supervise. # Deactivate a license/qualification Source: https://docs.byblend.com/api-reference/prescribers/deactivate-a-licensequalification /openapi-public.yml delete /api/v1/prescribers/{prescriber_id}/qualifications/{qualification_id} Deactivate a license/qualification for a prescriber. This does not delete the qualification, but rather sets it to inactive. # Get a prescriber's details Source: https://docs.byblend.com/api-reference/prescribers/get-a-prescribers-details /openapi-public.yml get /api/v1/prescribers/{prescriber_id} Retrieve details for a specific prescriber. # Get a prescriber's supervisees Source: https://docs.byblend.com/api-reference/prescribers/get-a-prescribers-supervisees /openapi-public.yml get /api/v1/prescribers/{prescriber_id}/supervisees Retrieve all supervisees for a specific prescriber. # Get a prescriber's supervisors Source: https://docs.byblend.com/api-reference/prescribers/get-a-prescribers-supervisors /openapi-public.yml get /api/v1/prescribers/{prescriber_id}/supervisors Retrieve all supervisors for a specific prescriber. # Get all available credentials Source: https://docs.byblend.com/api-reference/prescribers/get-all-available-credentials /openapi-public.yml get /api/v1/prescribers/credentials Retrieve a list of all available credentials. # Get all available prescribers Source: https://docs.byblend.com/api-reference/prescribers/get-all-available-prescribers /openapi-public.yml get /api/v1/prescribers Retrieve a list of all available prescribers. # Remove a supervisorial relationship Source: https://docs.byblend.com/api-reference/prescribers/remove-a-supervisorial-relationship /openapi-public.yml delete /api/v1/prescribers/{prescriber_id}/supervisors/{mapping_id} Delete a supervisorial relationship for a specific prescriber in a specific state. # Update a license/qualification Source: https://docs.byblend.com/api-reference/prescribers/update-a-licensequalification /openapi-public.yml put /api/v1/prescribers/{prescriber_id}/qualifications/{qualification_id} Update a license/qualification for a prescriber. As a shorthand, you may also update the currently-active state license by making the same request to .../qualifications/`OH` (or equivalent state abbreviation). # Update a prescriber's details Source: https://docs.byblend.com/api-reference/prescribers/update-a-prescribers-details /openapi-public.yml patch /api/v1/prescribers/{prescriber_id} Partial update — send only the fields to change. `PUT` is also accepted with identical merge semantics for backward compatibility. To update licenses or qualifications, use the dedicated endpoints. # Get a prescription Source: https://docs.byblend.com/api-reference/prescriptions/get-a-prescription /openapi-public.yml get /api/v1/prescriptions/{prescription_id} Retrieve an individual medication prescription by ID. # Get prescriptions Source: https://docs.byblend.com/api-reference/prescriptions/get-prescriptions /openapi-public.yml get /api/v1/prescriptions Retrieve prescriptions available to a user. This endpoint returns paginated responses. Details on pagination are returned in response headers. - `X-Total-Count`: total number of items available - `X-Page`: current page number - `X-Page-Size`: number of items per page - `X-Total-Pages`: total number of pages available - `X-Remaining-Count`: number of items remaining after the current page # Get non-prescription products Source: https://docs.byblend.com/api-reference/products-and-materials/get-non-prescription-products /openapi-public.yml get /api/v1/products/non_prescription Retrieve all non-prescription products. This endpoint returns paginated responses. Details on pagination are returned in response headers. - `X-Total-Count`: total number of items available - `X-Page`: current page number - `X-Page-Size`: number of items per page - `X-Total-Pages`: total number of pages available - `X-Remaining-Count`: number of items remaining after the current page # Get order materials Source: https://docs.byblend.com/api-reference/products-and-materials/get-order-materials /openapi-public.yml get /api/v1/products/order_material Retrieve all order materials. This endpoint returns paginated responses. Details on pagination are returned in response headers. - `X-Total-Count`: total number of items available - `X-Page`: current page number - `X-Page-Size`: number of items per page - `X-Total-Pages`: total number of pages available - `X-Remaining-Count`: number of items remaining after the current page # Get prescription products Source: https://docs.byblend.com/api-reference/products-and-materials/get-prescription-products /openapi-public.yml get /api/v1/products/prescription Retrieve all prescription products. This endpoint returns paginated responses. Details on pagination are returned in response headers. - `X-Total-Count`: total number of items available - `X-Page`: current page number - `X-Page-Size`: number of items per page - `X-Total-Pages`: total number of pages available - `X-Remaining-Count`: number of items remaining after the current page # Get products Source: https://docs.byblend.com/api-reference/products-and-materials/get-products /openapi-public.yml get /api/v1/products Retrieve all products and materials available for ordering, in separate object arrays. # Update a prescription product Source: https://docs.byblend.com/api-reference/products-and-materials/update-a-prescription-product /openapi-public.yml patch /api/v1/products/prescription/{product_id} Partial update — send only the fields to change. `PUT` is also accepted with identical merge semantics for backward compatibility. # Update non-prescription product Source: https://docs.byblend.com/api-reference/products-and-materials/update-non-prescription-product /openapi-public.yml patch /api/v1/products/non_prescription/{product_id} Partial update — send only the fields to change. `PUT` is also accepted with identical merge semantics for backward compatibility. # Update order materials Source: https://docs.byblend.com/api-reference/products-and-materials/update-order-materials /openapi-public.yml patch /api/v1/products/order_material/{product_id} Partial update — send only the fields to change. `PUT` is also accepted with identical merge semantics for backward compatibility. # Daily report Source: https://docs.byblend.com/api-reference/reports/daily-report /openapi-public.yml get /api/v1/reports/daily Retrieve daily counts of new patients, prescriptions and orders. Cancelled prescriptions and orders are excluded from the counts. # Orders report Source: https://docs.byblend.com/api-reference/reports/orders-report /openapi-public.yml get /api/v1/reports/orders Retrieve a report of orders by date range and status. # Search all Source: https://docs.byblend.com/api-reference/search/search-all /openapi-public.yml get /api/v1/search Search across orders, patients, prescribers, products and tasks. # Search orders Source: https://docs.byblend.com/api-reference/search/search-orders /openapi-public.yml get /api/v1/search/orders Search orders by order number, ID, patient fields, or a substring. # Search patients Source: https://docs.byblend.com/api-reference/search/search-patients /openapi-public.yml get /api/v1/search/patients Search patients by ID, name, email, phone, date of birth (MM/DD/YYYY or YYYYMMDD or YYYY-MM-DD), or a substring of the above. # Search prescribers Source: https://docs.byblend.com/api-reference/search/search-prescribers /openapi-public.yml get /api/v1/search/prescribers Search prescribers by ID, name, email, phone, or a substring. # Search products Source: https://docs.byblend.com/api-reference/search/search-products /openapi-public.yml get /api/v1/search/products Search products by name, SKU, or a substring. # Search tasks Source: https://docs.byblend.com/api-reference/search/search-tasks /openapi-public.yml get /api/v1/search/tasks Search tasks by name, description, or a substring. # How do I add a prescriber to Blend? Source: https://docs.byblend.com/guides/add-a-prescriber POST /api/v1/prescribers with first_name, last_name, phone, npi, and at least one credential. If the NPI already exists in Blend, the existing prescriber is returned and associated with your account. `POST /api/v1/prescribers` requires five things: `first_name`, `last_name`, `phone`, `npi`, and at least one entry in `credentials`. Everything else — addresses, DEA and SPI numbers, state licenses, supervisors — can be added at creation or later. Prescribers must exist in Blend before their prescriptions can be filled. Blend imports them in bulk during onboarding; this endpoint is for the ones you add afterwards. ## Create one ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/prescribers \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "first_name": "Willard", "last_name": "Donnelly", "phone": "6417383445", "email": "wdonnelly@clinic.example.com", "npi": "1234567890", "dea": "F91234563", "spi": "1234567890ABCDEF", "credentials": [{ "credential_code": "MD" }], "addresses": [{ "type": "practice", "address_1": "140 Lindgren Street", "city": "Boston", "state": "MA", "zip_code": "02108" }], "qualifications": [{ "state": "MA", "license_number": "1234567890", "expiration_date": "2027-03-15" }] }' ``` * **`credential_code`** — pull valid values from `GET /api/v1/prescribers/credentials`. * **`addresses[].type`** — `practice` or `working`. * **`qualifications`** — state licenses; see [keeping prescriber licenses current](/guides/prescriber-licenses). ## If the prescriber already exists Blend deduplicates on **NPI**. If you post a prescriber who already exists, the existing record is returned rather than an error. If they exist elsewhere in Blend but not yet under your account, they are associated with your account. Posting the same prescriber twice is safe. This makes the endpoint effectively idempotent by NPI — useful when syncing a roster where you can't easily tell what's already been sent. ## Restricting what a prescriber can prescribe The `restrictions` array holds prescription product IDs the prescriber may **not** prescribe. Use it where your own policy is narrower than the prescriber's license. ## Supervisory relationships Where a prescriber practises under supervision, record it per state: ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/prescribers/1234567890/supervisors \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "supervisor_id": "0227d1e5-ba9a-42b5-8fe2-38882aa65708", "state": "CA" }' ``` A supervisor must hold a valid qualification in at least one state before they can supervise. Create their license first. The path accepts a **10-digit NPI** anywhere a prescriber UUID is expected — you don't need to store Blend IDs for prescribers at all. See [using your own IDs](/guides/your-own-ids). Prescribers are also fully manageable in the Blend Dashboard under Prescribers, where clinical and compliance staff can add licenses, credentials, and supervisors without touching the API. POST /prescribers Valid `credential_code` values Per-state supervision PATCH /prescribers/prescriber\_id # How do I authenticate with the Blend API? Source: https://docs.byblend.com/guides/authentication POST /api/v1/auth/login with your email and password to get a JWT access token. Send it as a Bearer token on every other request. Access tokens last 60 minutes; refresh tokens last 7 days. Every Blend API request is authenticated with a JWT bearer token. You get one by posting your Blend credentials to `/api/v1/auth/login`, which returns both an `access_token` (valid 60 minutes) and a `refresh_token` (valid 7 days). Send the access token as `Authorization: Bearer {access_token}` on every subsequent call. The base URL is `https://api.byblend.com`. ## Get a token ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/auth/login \ -H "Content-Type: application/json" \ -d '{ "email": "integrations@yourclinic.com", "password": "your-password" }' ``` Use the returned `access_token` on everything else: ```bash theme={null} curl https://api.byblend.com/api/v1/orders \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." ``` ## Refresh before you expire When the access token expires, call `/api/v1/auth/refresh` to get a new one without re-sending credentials. The refresh endpoint expects the **refresh token** in the `Authorization` header — not the access token. Sending the access token here is the single most common integration mistake. ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/auth/refresh \ -H "Authorization: Bearer {refresh_token}" ``` Refresh on a timer or on a `401`, rather than logging in fresh for every request. A 60-minute access token comfortably covers a batch job; a 7-day refresh token covers a week of unattended operation. ## Check a token without spending a request `GET /api/v1/auth/verify` returns whether the current token is still valid, along with the user it belongs to — useful for health checks and for confirming which Blend account an integration is running as. ## Service accounts Create a dedicated Blend user for your integration rather than authenticating as a person. Integration activity then shows up distinctly in order history and audit trails, and a staff member leaving your organization never breaks your pipeline. POST /auth/login POST /auth/refresh GET /auth/verify # How do I cancel an order in Blend? Source: https://docs.byblend.com/guides/cancel-an-order PUT /api/v1/orders/{order_id}/cancel works while the order is in received, paused, or exception. Once it's picked or verified, use PUT /orders/{order_id}/request_cancellation instead — the products have to come back off the bench first. Which endpoint you use depends on whether the order has been physically picked. **Not yet picked** — `PUT /api/v1/orders/{order_id}/cancel` cancels it immediately. Valid from `received`, `paused`, or `exception`. **Already picked or verified** — `PUT /api/v1/orders/{order_id}/request_cancellation` raises a request for pharmacy staff. It does **not** change the order's status. ```bash theme={null} curl -X PUT https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/cancel \ -H "Authorization: Bearer {access_token}" ``` ## Requesting cancellation on a picked order ```bash theme={null} curl -X PUT https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/request_cancellation \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "reason": "Patient changed their mind" }' ``` The `reason` is optional but genuinely useful — it reaches the staff member who handles the request. **Request cancellation does not cancel the order.** It sets `cancellation_requested: true` and leaves the status alone. Don't treat a successful response as confirmation the order is dead — poll the order or subscribe to a webhook to see the real outcome. **Only one cancellation request per order is allowed.** A second call is rejected. If circumstances change, contact Blend support rather than re-requesting. ## Why picked orders work differently Once an order has been picked, its contents are physically off the shelf and inventory has already been decremented. Blend does not mark the order cancelled until staff have unpicked the products and returned them to stock, so that inventory stays accurate. The request is picked up at pharmacist verification or at shipping, the products are returned, and the order is then cancelled. ## Deciding which to call | Order status | What to use | | - | - | | `received` | `/cancel` | | `paused` | `/cancel` | | `exception` | `/cancel` | | `picked` | `/request_cancellation` | | `verified` | `/request_cancellation` | | `shipped`, `delivered` | Neither — see below | Check the current status first with `GET /orders/{order_id}`, or simply attempt `/cancel` and fall back to `/request_cancellation` on rejection. An order that has already shipped cannot be cancelled. If the shipment was wrong, [request a replacement](/guides/replacement-orders) instead. Cancelling an **order** does not cancel the underlying **prescription**. The prescription keeps its remaining fills and can be ordered against again. If Blend auto-creates your orders from prescriptions, a cancelled order may simply regenerate unless the prescription is dealt with too — see [editing an order](/guides/edit-an-order). Both actions are available on the order page in the Blend Dashboard, which is where most customer-service cancellations happen. `received`, `paused`, `exception` `picked`, `verified` Hold instead of cancel Confirm what actually happened # How do I create a patient, prescription, and order in one API call? Source: https://docs.byblend.com/guides/composite-creation POST /api/v1/prescriptions/electronic_prescriptions/composite with any combination of patient, prescriber, electronic_prescription, and order objects. It is all-or-nothing: if one entity fails, nothing is created. Blend's composite endpoint creates a patient, a prescriber, an electronic prescription, and an order in a single request. Post any combination of the four top-level objects — `patient`, `prescriber`, `electronic_prescription`, `order` — and each one follows the same required fields as its individual endpoint. Patients and prescribers can be **referenced** instead of created, so a returning patient doesn't need their profile re-sent. The whole request is atomic. If any single entity fails validation, the entire request fails and nothing is created. ## A new patient, new prescription, and order in one request ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/prescriptions/electronic_prescriptions/composite \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "patient": { "first_name": "Willard", "last_name": "Donnelly", "email": "wdonnelly@example.com", "phone": "6417383445", "date_of_birth": "1990-01-01", "external_id": "clinic-pt-4471", "address": { "address_1": "140 Lindgren Street", "city": "Boston", "state": "MA", "zip_code": "02108" } }, "prescriber": { "npi": "1234567890" }, "electronic_prescription": { "medication": { "product_code": "HC-RAPA31", "drug_name": "Rapamycin", "quantity": 30, "units": "C48480", "days_supply": 30, "refills": 4, "sig": "Take one capsule by mouth once weekly", "written_at": "2026-08-20T00:00:00" } }, "order": { "products": { "prescription": [ { "product_code": "HC-RAPA31", "quantity": 1 } ] } } }' ``` The response returns `{ id, created }` for each entity plus a `summary` reporting `entities_created` and `entities_referenced` — so you can tell at a glance whether the patient was newly created or matched to an existing record. ## Referencing instead of creating For a returning patient, drop the full profile and pass a reference: ```json theme={null} "patient": { "external_id": "clinic-pt-4471" } ``` Prescribers can be referenced by `id` or `npi`. See [how Blend matches entities](/overview#how-blend-matches-patients-orders-prescribers-prescriptions-and-products) for the full matching rules. **All-or-nothing.** A malformed address on the patient means the prescription and order are not created either. Validate each object against its individual endpoint's requirements before combining them. **Order merging still applies.** If the patient already has an open order, the order in your composite request merges into it. Pass `force_new=true` as a querystring argument to prevent that — see [Order Merging](/overview#order-merging). ## When to use it Reach for composite when your system already holds everything at once — a checkout flow, an intake form, an EMR pushing a completed visit. Use the individual endpoints when entities arrive at different times, which is the more common pattern for businesses whose prescriptions come through Surescripts. POST /prescriptions/electronic\_prescriptions/composite POST /orders POST /patients POST /prescriptions/electronic\_prescriptions # How do I record why a compound was needed? Source: https://docs.byblend.com/guides/compounding-reasons Attach a reasons array to each prescription line when creating an order. Pull the available reasons from GET /api/v1/reasons, or create your own with POST /api/v1/reasons. Compounding reasons record the clinical justification for a compounded preparation — why this patient needed a compound rather than a commercially available product. Attach them per prescription line at order creation using the `reasons` array. Blend ships a set of global reasons organized as parent categories with subcategories. You can add your own, and nest them under a global parent or one of your own. ## See what's available ```bash theme={null} curl https://api.byblend.com/api/v1/reasons \ -H "Authorization: Bearer {access_token}" ``` Reasons come back as parent categories each containing `subcategories` — for example "Adherence or Compliance" containing "Behavioral Issues", alongside standalone categories such as "Palatability". Filter with `type=global` or `type=customer` to separate Blend's list from your own. ## Attach them to an order line ```json theme={null} { "patient": { "external_id": "clinic-pt-4471" }, "products": { "prescription": [ { "product_code": "HC-RAPA31", "quantity": 1, "reasons": [ { "id": "0227d1e5-ba9a-42b5-8fe2-38882aa65708" } ] } ] } } ``` Reasons attach to the **line item**, not the order. An order containing three compounded products can carry a different justification for each. ## Create your own ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/reasons \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "name": "Physical location", "description": "Patient cannot access a physical pharmacy due to natural disaster or similar event.", "parent_id": "0227d1e5-ba9a-42b5-8fe2-38882aa65708" }' ``` Both `name` and `description` are required. `parent_id` is optional — supply it to nest the reason under a global category or one of your own, or omit it to create a top-level category. Give the `description` real substance. It's the text that explains the clinical rationale to anyone reviewing the record later, and a vague description makes the reason much less useful than no reason at all. Prefer an existing global reason over creating a near-duplicate. A short, shared vocabulary reports far better across your whole order history than dozens of one-off custom reasons that mean the same thing. Custom reasons can be updated later with `PUT /api/v1/reasons/{reason_id}`. Global and custom, with subcategories POST /reasons PUT /reasons/reason\_id `reasons` on each prescription line # How do I create a patient in Blend? Source: https://docs.byblend.com/guides/create-a-patient POST /api/v1/patients with first_name, last_name, email, phone, date_of_birth, and address. Send your own external_id too — it makes prescription matching definitive. Duplicates return a 400 with the existing patient's ID. `POST /api/v1/patients` creates a patient. Six fields are required: `first_name`, `last_name`, `email`, `phone`, `date_of_birth`, and an `address` object with `address_1`, `city`, `state`, and `zip_code`. Everything else is optional, but `external_id` is worth sending on every patient — it's what makes prescription matching definitive rather than a name lookup. A patient must exist before an order can be placed for them, though a prescription can arrive first and wait. ## Create one ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/patients \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "first_name": "Willard", "last_name": "Donnelly", "email": "wdonnelly@example.com", "phone": "6417383445", "date_of_birth": "1990-01-01", "external_id": "clinic-pt-4471", "gender": "male", "height_inches": 72, "weight_pounds": 180, "address": { "address_1": "140 Lindgren Street", "address_2": "Apt 227", "city": "Boston", "state": "MA", "zip_code": "02108" }, "risk_factors": { "allergies": "peanuts, tree nuts, shellfish", "conditions": "asthma, hypertension" } }' ``` Formatting rules worth knowing up front: * **`phone`** — 10 digits, no formatting: `6417383445`, not `(641) 738-3445`. * **`state`** — two-letter abbreviation. **`country`** defaults to `US`. * **`zip_code`** — 5-digit or ZIP+4. * **`date_of_birth`** — `YYYY-MM-DD`. * **`ssn`** — accepted with or without hyphens. ## Handling a duplicate If the patient already exists, Blend returns **400** with a body that names the existing record: `error`, `existing_patient_id`, and `existing_patient_external_id` when that record has one. Treat this as a successful lookup, not a failure — read `existing_patient_id` and continue with it rather than retrying. Duplicate detection runs **within your own customer account**, matching on name plus date of birth, or on `external_id`. ```python theme={null} r = requests.post(url, json=payload, headers=headers) if r.status_code == 400 and "existing_patient_id" in r.json(): patient_id = r.json()["existing_patient_id"] else: patient_id = r.json()["id"] ``` ## Minors and guardians If the patient is a minor, `guardian_name` is required. `guardian_phone`, `guardian_email`, and `guardian_relationship` complete the record — pull valid relationship values from `GET /patients/guardian_relationship_types`; `parent` and `legal_guardian` are the common ones, and `other` is accepted. ## Patient notifications `receive_sms` and `receive_email` control whether the patient gets shipment notifications directly from Blend. These flags only take effect if you have authorized Blend to send patient communications on your behalf. If you haven't, setting them has no effect — patient contact stays entirely with your business. ## Creating a patient inline You don't have to call this endpoint separately. Both `POST /orders` and the [composite endpoint](/guides/composite-creation) accept a full `patient` object and will create the patient as part of the same request — or accept `{ "external_id": "..." }` to reference an existing one. Patients can also be created and edited in the Blend Dashboard, and Blend can bulk-import your existing patient roster during onboarding — useful when you're bringing over refill prescriptions for established patients. POST /patients PATCH /patients/patient\_id Valid `guardian_relationship` values By UUID or your `external_id` # How do I edit an order after it's been created? Source: https://docs.byblend.com/guides/edit-an-order Add, change, or remove line items while the order is in received status. Address, external_id, and shipping preferences use PATCH /api/v1/orders/{order_id} and stay editable later in the pipeline. There are two different editing windows on a Blend order, and confusing them is the most common source of unexpected `400`s. **Line items** — adding products, changing quantities, removing a line — are editable while the order is in `received`. Once picking begins, the contents are fixed. **Address, `external_id`, and shipping preferences** go through `PATCH /api/v1/orders/{order_id}` and remain editable further into the pipeline. Shipping options, including address, can be edited up until the moment a shipping label has been purchased. ## Add products to an existing order ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/products \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "prescription": [ { "product_code": "HC-RAPA31", "quantity": 1 } ], "non_prescription": [ { "sku": "SHARPS-SM", "quantity": 2 } ] }' ``` Product references follow the same rules as order creation: Blend `id`, your `sku`, or `product_code` for prescription products. ## Change or remove a line ```bash theme={null} # Change quantity curl -X PATCH "https://api.byblend.com/api/v1/orders/{order_id}/products/prescription/{id}" \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "quantity": 2 }' # Remove the line curl -X DELETE "https://api.byblend.com/api/v1/orders/{order_id}/products/prescription/{id}" \ -H "Authorization: Bearer {access_token}" ``` `product_type` in the path is one of `prescription`, `non_prescription`, or `order_material`. If the **same product appears more than once** on an order, you must pass the `order_item_id` query parameter to say which line you mean. Take the value from the order's `products` object. Without it, Blend can't disambiguate. ## Update the address, external ID, or shipping ```bash theme={null} curl -X PATCH "https://api.byblend.com/api/v1/orders/ORD250312003548IAU4?update_patient=true" \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "address": { "address_1": "22 Beacon Street", "city": "Boston", "state": "MA", "zip_code": "02108" }, "external_id": "my-system-128318AA2" }' ``` This is a partial update — send only the fields you're changing. `PUT` is accepted with identical merge semantics for backward compatibility. `update_patient=true` writes the new address back to the **patient record** as well as the order. Without it, only this one order moves. Use it for a genuine relocation; omit it for a one-time ship-to-somewhere-else. ## Removing a line from an auto-created order If Blend creates your orders automatically from inbound prescriptions, removing a prescription line is not enough on its own — the order is generated **from** the prescription, so the line is simply re-added. You also have to decide what happens to the underlying prescription. Cancelling or pausing the prescription is what makes the removal stick. ## When editing isn't the right tool * The whole order shouldn't ship → [cancel it](/guides/cancel-an-order) * It should ship, but later → [pause it](/guides/pause-an-order) * It shipped and was wrong → [request a replacement](/guides/replacement-orders) * Only the carrier or service level is wrong → [shipping preferences](/guides/shipping-preferences) Orders are editable in the Blend Dashboard under the same rules, which is usually faster for a one-off correction than writing an API call. POST /orders/order\_id/products PATCH a single line DELETE a single line Address, external ID, shipping # Why can't Blend find a prescription I sent? Source: https://docs.byblend.com/guides/find-a-missing-prescription Almost always the prescription arrived but didn't match — a name or date-of-birth typo, a patient who doesn't exist in Blend yet, or a product code that isn't mapped. Blend does not discard prescriptions. If a prescription is missing from a patient's chart, it has usually arrived and simply failed to match. Blend does not silently discard prescriptions. Three causes account for nearly all of it: a typo in the patient's name or date of birth, a patient who hasn't been created in Blend yet, or a product code that isn't mapped to one of your products. If a prescription you sent hasn't matched, the Blend team will typically find and address it. ## Check which link is missing ```bash theme={null} # Prescriptions that arrived with no patient attached curl "https://api.byblend.com/api/v1/prescriptions?patient_id=null&page_size=200" \ -H "Authorization: Bearer {access_token}" # Prescriptions that never matched a product in your catalog curl "https://api.byblend.com/api/v1/prescriptions?prescription_product_id=null&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` If the prescription shows up in the first query, it's a patient-matching problem. If it shows up in the second, it's a product-mapping problem. ## The three typical mismatches **The patient doesn't exist in Blend yet.** A prescription can legitimately arrive before its patient. It waits, unmatched, until the patient is created — at which point Blend links it. Create the patient with `POST /patients`, ideally carrying the same `external_id` your prescriptions reference. **The product code isn't mapped.** Blend looks for your `product_code`, `sku`, `id`, or `name` in the inbound prescription. If none of those are set on the product in Blend, nothing matches. Set them with `PATCH /products/prescription/{product_id}`. **The name or date of birth is wrong on the prescription.** Surescripts prescriptions match on name plus date of birth, so when the inbound data carries a typo — a transposed birth year, a misspelled surname — no automatic match is possible. Typos originate upstream, at the prescriber's office or a transferring pharmacy, which is why the prescription itself is intact but unmatched. Send `external_id` on your patients and reference it in your prescriptions. Identifier matching is definitive and immune to spelling — it removes this entire class of problem. See [using your own IDs](/guides/your-own-ids). ## A prescription with no order is not a missing one Blend receives far more prescriptions than orders. A prescription sitting with no order attached is usually just waiting for the patient to order, not lost. What's worth escalating is an **order** that can't ship — see [finding orders missing prescriptions](/guides/orders-missing-prescriptions). `patient_id=null`, `prescription_product_id=null` POST /patients Map `product_code` and `sku` Patient, product, and order rules # Blend API and User Guides Source: https://docs.byblend.com/guides/index Task-focused answers for building on the Blend API and working in the Blend Dashboard — sending prescriptions, creating orders, handling exceptions, and managing prescribers, products, and reporting. ## Getting started Bearer tokens, 60-minute expiry, refresh flow The composite endpoint external\_id, sku, and product\_code Headers, not body metadata Webhook and email subscriptions Orders, patients, prescribers, products ## Prescriptions SCRIPT XML or JSON, non-controls The matching rules, in order has\_unmatched\_prescriptions Typical mismatches and how they clear License coverage vs next fill ## Patients Required fields and duplicate handling Freeform risk factors Inboxes, routing, and replies ## Orders Merging and force\_new Two different editing windows Shipping and signature confirmation Cancel vs request cancellation Indefinite and timed holds Doesn't consume a fill Exceptions and what clears them All nine, and what each allows Set quantity on every line ## Prescribers Required fields, NPI deduplication Qualifications and renewals NPI and DEA registry monitoring ## Products and catalog id, sku, and product\_code Compounding reasons ## Reporting and operations Daily and orders reports Six sections, brand roll-ups Brand, customer, location The receiving pharmacy requests it # What's in the Blend Metrics report? Source: https://docs.byblend.com/guides/metrics-report Six sections — Turnaround, Patients, Stuck, Invoicing, Replacements, and Utilization — over any date range, scoped to one business or rolled up across a whole brand, with comparison against the prior period. The Metrics report in the Blend Dashboard is the operational view of your account: how fast orders move, how many patients are new versus returning, what's getting stuck, what you're spending, how often replacements happen, and which products and prescribers drive volume. Choose a date range, scope it to a single business or roll it up across an entire brand, and each section compares against the prior period. Find it under **Metrics** in the Blend Dashboard. ## The six sections Average time from order received to shipped, with time spent blocked in exception excluded — so a stuck order doesn't distort your fulfillment speed. New versus returning patients in the period. The clearest read on whether growth is acquisition or retention. Orders and prescriptions created in the period that hit an exception, broken out by reason — so you can see which blockers are systemic. Product, fill, and shipping spend, windowed on ship date. Replacement order rate against orders created in the window — your quality signal. Product volume, optionally broken down by prescriber. ## Turnaround, measured two ways Turnaround is reported both as **wall-clock** time and against **pharmacy operating hours**. The distinction matters more than it sounds. An order received at 9pm and shipped at noon the next day is fifteen hours on the clock, but only a few operating hours — and the second number is the one that reflects how the pharmacy actually performed. Judge fulfillment speed on business hours; set patient expectations on wall clock. Time an order spends in `exception` is excluded from turnaround. A stuck order waiting on a missing prescription isn't a fulfillment delay, and counting it as one would hide real performance changes. ## Scoping and comparison * **One business, or a whole brand.** Scope to a single customer, or roll up across every business under a brand. See [multi-brand and multi-location support](/guides/multitenancy). * **Filter to a location.** Where a business operates several locations, narrow to one. * **Compare against the prior period.** Each section reports change against the preceding comparable window, so a number is always in context. * **Deep-link a section.** The active tab is reflected in the URL, so you can send a colleague straight to the view you're looking at. Sections export to CSV, so a monthly board pack or a finance reconciliation doesn't mean retyping figures. The report is also laid out to print cleanly. ## Metrics versus the API reports | | Metrics report | [API reports](/guides/reports) | | - | - | - | | Where | Blend Dashboard | `GET /reports/daily`, `GET /reports/orders` | | Best for | Reviewing performance, spotting trends | Feeding your own systems | | Depth | Turnaround, spend, utilization, replacements | Counts by day and by status | | Scope | Customer, brand, or location | Your account | Use Metrics when a person needs to understand what happened. Use the API reports when a system needs the numbers. Pull counts programmatically How brand roll-ups work What the Stuck section is counting What drives the replacement rate # Can Blend support multiple brands, franchises, and locations? Source: https://docs.byblend.com/guides/multitenancy Yes. Blend models a brand above its clinics, and locations beneath them, so a franchisor with many owners, an owner with many sites, and a single independent clinic all work in the same system. Blend is built for organizations that aren't a single clinic. The data model has three tiers — **brand**, **customer**, and **location** — and you use as many of them as your structure needs. A franchisor with dozens of independent owners, an owner running several sites, and a standalone practice are all first-class shapes, not workarounds. Everything scopes to the tier it belongs to: products can be shared across a brand or overridden per clinic, users can be granted brand-wide access or held to one clinic, and reporting rolls up or drills down accordingly. ## The three tiers The shared identity above a group of clinics. Owns brand-level products and gives brand-wide users and reporting a place to sit. An individual clinic or franchise owner — in Blend, "customer" and "clinic" mean the same thing. The account that owns patients, prescriptions, and orders, and the tier the API operates at. A physical site under a clinic, with its own business name, address, and phone. Used to route inbound prescriptions and to filter reporting. ## Shared catalog, local overrides Products can be defined once at the brand level and shared by every clinic underneath, while any individual clinic can override the parts that differ for them — display name, SKU, product code, pricing. An override is a variation on the **same** product, not a separate one. That's what makes brand-wide reporting meaningful: thirty clinics selling the same preparation under thirty local names still roll up as one product. Which products a clinic sees is configurable. A clinic can inherit the full catalog and have specific items removed, or start from nothing and have items added deliberately — and either way it keeps its own custom formulations. ## Access across clinics Users can be scoped to one clinic, or granted **brand-level** access spanning every clinic beneath the brand. A brand user can act for one clinic or all of them, and sees orders, patients, prescribers, products, stuck orders, patient messaging, and metrics across the group. They can create orders, edit patient and prescriber data, respond to patients, and work stuck orders — the same actions, over a wider scope. ## Reporting that rolls up The [Metrics report](/guides/metrics-report) scopes to a single clinic, to an entire brand, or to a single location within a clinic. A franchisor can compare turnaround across every owner in the group; an owner can compare their own sites; a single clinic sees only itself. ## Routing prescriptions to the right place Each location carries its own business name, which is what lets Blend attribute an inbound prescription to the right site — important when several locations under one clinic prescribe under distinct practice names. ## What this means for your integration The API operates at the **customer** level. Your credentials are scoped to a clinic, and patients, prescriptions, and orders belong to that clinic. If you integrate on behalf of several clinics in a brand, you'll typically hold credentials per clinic — which also keeps each clinic's data cleanly separated. Talk to your Blend contact about your structure before onboarding. Whether prescribers, patients, and products should be shared across a brand or kept separate per clinic is a decision worth making deliberately at setup, and it's much easier to get right up front than to reorganize later. Brand roll-ups and location filters SKUs and product codes per clinic Credentials are scoped per clinic Prescribers associate across accounts by NPI # Why did my new order merge into an existing one? Source: https://docs.byblend.com/guides/order-merging Blend consolidates open orders for the same patient by default, so a patient gets one box instead of three. The response returns the original order with merged_into_existing: true. Pass force_new=true to prevent it. When you create an order for a patient who already has an open order, Blend merges the new one into it. You receive the **existing** order in the response, with `"merged_into_existing": true` to confirm what happened. This is deliberate: it means a patient who orders three times in a morning gets one shipment rather than three. An order is mergeable while it is in `received` or `paused` status, or is an `exception` (stuck) order created within the last 24 hours. Once it reaches `picked` or later, a new order is created instead. ## What you get back ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/orders \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "patient": { "external_id": "clinic-pt-4471" }, "products": { "prescription": [{ "product_code": "HC-RAPA31", "quantity": 1 }] } }' ``` ```json theme={null} { "id": "0227d1e5-ba9a-42b5-8fe2-38882aa65708", "order_number": "ORD250312003548IAU4", "status": "received", "merged_into_existing": true } ``` The `id` and `order_number` in the response belong to the **original** order, not a new one. If your system assumes every create returns a distinct order, a merge will look like a duplicate ID. Always check `merged_into_existing`. ## Preventing a merge Pass `force_new=true` as a querystring argument: ```bash theme={null} curl -X POST "https://api.byblend.com/api/v1/orders?force_new=true" \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "patient": { "external_id": "clinic-pt-4471" }, "products": { ... } }' ``` The same parameter works on the [composite endpoint](/guides/composite-creation). Use it when the orders genuinely must stay separate — most commonly when a patient has asked for one order to go to a different address. ## What happens to shipping on a merge Shipping details on the new request are **inherited by the existing order**: * A new shipping address replaces the original one — the whole merged order goes to the new address. * A new shipping preference (carrier or service level) replaces the original. This is the reason to reach for `force_new=true` when a patient wants a separate delivery. Without it, a second order bound for a different address will silently redirect the first one too. ## Which orders can be merged into An order can be merged into while it is: * in `received` status, * in `paused` status, or * an `exception` (stuck) order **created within the last 24 hours**. The 24-hour window on stuck orders lets same-day prescriptions still ship together when a hold is released, while making sure a long-standing hold on one medication doesn't delay unrelated new prescriptions. Once an order reaches `picked` or later, it is locked and a new order is created for that patient instead. See [Order Merging](/overview#order-merging) for the canonical description, and [order statuses](/guides/order-statuses) for what each stage means. Merging also happens for orders created in the Blend Dashboard, and for orders Blend creates automatically from inbound prescriptions. It is a property of the order pipeline, not of the API. Accepts `force_new` Also accepts `force_new` Canonical rules in the overview See what's already open # Why doesn't my order quantity match the prescribed quantity? Source: https://docs.byblend.com/guides/order-quantities They measure different things. A prescription quantity is in the prescriber's units — 20 mL. An order line quantity counts sellable units — 2 vials. Set quantity explicitly on every order line. Blend tracks quantity at three different layers, and they are not interchangeable. * **Prescription quantity** — what the prescriber wrote, in clinical units. *20 mL.* * **Order line quantity** — how many sellable units to dispense. *2 vials.* * **Dispensed quantity** — what was actually pulled at pick time, recorded on the fill. ## When you create the order Blend does **not** compute the line quantity for you. If you omit `quantity` on an order line, it defaults to **1** — regardless of what the prescription says. A 90-capsule prescription with no `quantity` on the order line ships one bottle. Send it explicitly: ```json theme={null} { "patient": { "external_id": "clinic-pt-4471" }, "products": { "prescription": [ { "product_code": "HC-RAPA31", "quantity": 2 } ] } } ``` ## How many fills does that consume? At pick time, Blend works out how many refills the dispensed amount represents: | Prescription | Ordered | Fills consumed | | - | - | - | | 90 capsules, 90 per bottle | 1 bottle | 1 | | 30 capsules, 90 per bottle | 90 capsules | 3 | | 20 mL, 10 mL vials | 2 vials | 1 | `fills_remaining` on the prescription is the number to trust — it accounts for how much each fill actually consumed, and it excludes fills created by [replacement orders](/guides/replacement-orders), which deliberately don't count against the prescription. Set `quantity` on every line Correct a line in `received` `quantity`, `units`, `fills_remaining` NCPDP unit codes # What do Blend's order statuses mean? Source: https://docs.byblend.com/guides/order-statuses received, picked, verified, exception, paused, shipped, delivered, cancelled, and returned. Which actions are available — cancelling, editing lines, changing shipping — depends entirely on which status an order is in. Blend orders move through nine statuses. Read `status` on any order, or call `GET /api/v1/orders/statuses` for the live list rather than hardcoding it. | Status | What it means | | - | - | | `received` | Accepted and queued. The only status in which line items can be added, changed, or removed. | | `picked` | Products pulled from inventory and inventory decremented. Line items are now fixed. | | `verified` | Passed pharmacist verification and entered the shipping process. | | `exception` | Also known as a "stuck order". Blocked by something. Steps out of the queue and returns to its prior position when cleared. | | `paused` | Deliberately held, indefinitely or until a date. | | `shipped` | Label purchased and shipment dispatched. Tracking is available. | | `delivered` | Carrier-confirmed delivery. Final. | | `cancelled` | Cancelled. | | `returned` | Returned to Blend. Final. | ## What you can do in each status | Action | Available in | | - | - | | Add / change / remove line items | `received` | | Cancel directly | `received`, `paused`, `exception` | | Request cancellation | `picked`, `verified` | | Pause | `received`, `exception` | | Unpause | `paused` | | Change shipping preferences | While a label hasn't been purchased — through `verified` | | Request a replacement | After the order has shipped | ## Reading the history ```bash theme={null} curl https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/status_history \ -H "Authorization: Bearer {access_token}" ``` This is the endpoint to reach for when an order isn't where you expect. It shows every transition, which usually explains the current state faster than reasoning about it. **Orders can move backwards.** When a prescription is matched to a line on a `picked` or `verified` order, the contents have changed, so the order returns to `received` for re-picking. This is correct behavior, not a fault. Don't write state machines that assume forward-only transitions. `exception` and `paused` both preserve the status the order came from, so unpausing or resolving an exception returns it to its place rather than to the start. ## Statuses these are not A few things look like statuses but aren't: * **`cancellation_requested`** and **`priority_requested`** are **flags**. Requesting cancellation or priority does not change the order's status — see [cancelling an order](/guides/cancel-an-order). * **`replacement_request_status`** is its own enum (`pending`, `fulfilled`, `declined`, `cancelled`) describing a request, not the order. * **Shipment status** is separate again (`shipped`, `cancelled`, `delivered`) and lives on the shipment inside the order. An order can have more than one shipment. * **Prescription status** is an entirely different lifecycle from order status. ## Filtering by status ```bash theme={null} curl "https://api.byblend.com/api/v1/orders?status=picked,verified" \ -H "Authorization: Bearer {access_token}" ``` Comma-separate to match several. This is far cheaper than paging the full list and filtering client-side. Rather than polling for status changes, subscribe to webhooks for `order.shipped` and `order.delivered` — see [getting notified when an order ships](/guides/webhooks). The live enum Every transition `status=` accepts a comma list What `exception` really means # How do I find orders that are missing prescriptions? Source: https://docs.byblend.com/guides/orders-missing-prescriptions Call GET /api/v1/orders?has_unmatched_prescriptions=true to list orders containing prescription products with no prescription attached. Use GET /prescriptions?has_order=false for the reverse. An order containing a prescription product can't be filled until an active, non-expired prescription with fills remaining is attached to it. `GET /api/v1/orders?has_unmatched_prescriptions=true` returns exactly the orders in that state, so you can chase the missing prescriptions before they become stuck orders. The mirror-image query — prescriptions that haven't been attached to any order — is `GET /api/v1/prescriptions?has_order=false`. ## Find the gap from the order side ```bash theme={null} curl "https://api.byblend.com/api/v1/orders?has_unmatched_prescriptions=true&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` Each returned order includes `prescription_count` and its `products`, so you can see which line is unaccounted for. ## And from the prescription side ```bash theme={null} curl "https://api.byblend.com/api/v1/prescriptions?has_order=false&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` `has_order` only supports `false`. There is no `has_order=true` — to find prescriptions that *do* have orders, query the patient's orders directly with `GET /patients/{patient_id}/orders`. ## Narrow it down The prescriptions list accepts filters that isolate exactly what's broken: ```bash theme={null} # Prescriptions that arrived with no patient attached curl "https://api.byblend.com/api/v1/prescriptions?patient_id=null" \ -H "Authorization: Bearer {access_token}" # Prescriptions that never matched one of your products curl "https://api.byblend.com/api/v1/prescriptions?prescription_product_id=null" \ -H "Authorization: Bearer {access_token}" ``` Passing `null` to `patient_id`, `prescription_product_id`, or `prescriber_id` finds prescriptions where that link is missing — which usually tells you *why* the order is unmatched, not just *that* it is. ## Fixing what you find If the prescription genuinely never arrived, [send it](/guides/send-electronic-prescription). If it did arrive but didn't match, the Blend team will typically find and address the issue (the problem is nearly always the product or patient match). See [how matching works](/guides/prescription-matching) and [why Blend can't find a prescription you sent](/guides/find-a-missing-prescription). `has_unmatched_prescriptions=true` `has_order=false`, `patient_id=null` GET /patients/patient\_id/orders GET /patients/patient\_id/prescriptions # How does pagination work in the Blend API? Source: https://docs.byblend.com/guides/pagination Paginated list endpoints return a flat JSON array and put the pagination metadata in response headers — X-Total-Count, X-Page, X-Page-Size, X-Total-Pages, and X-Remaining-Count. Page size defaults to 25 and maxes at 200. Blend's list endpoints return a **flat JSON array**, not a wrapped object. Pagination metadata lives in the response headers instead of the body, so you read `X-Total-Count` and friends rather than looking for a `total` key. Control the window with the `page` and `page_size` query parameters; `page_size` defaults to 25 and is capped at 200. ## Read the headers ```bash theme={null} curl -i "https://api.byblend.com/api/v1/orders?page=2&page_size=50" \ -H "Authorization: Bearer {access_token}" ``` ```http theme={null} HTTP/1.1 200 OK X-Total-Count: 438 X-Page: 2 X-Page-Size: 50 X-Total-Pages: 9 X-Remaining-Count: 338 Content-Type: application/json [ { "id": "0227d1e5-...", "order_number": "ORD250312003548IAU4", ... } ] ``` | Header | Meaning | | - | - | | `X-Total-Count` | Total items available across all pages | | `X-Page` | The page you just received | | `X-Page-Size` | Items per page | | `X-Total-Pages` | Total pages available | | `X-Remaining-Count` | Items left after this page | ## Loop until you've drained it `X-Remaining-Count` is the cleanest stopping condition — keep requesting until it reaches `0`. ```python theme={null} page = 1 while True: r = requests.get( "https://api.byblend.com/api/v1/orders", params={"page": page, "page_size": 200}, headers={"Authorization": f"Bearer {token}"}, ) yield from r.json() if int(r.headers["X-Remaining-Count"]) == 0: break page += 1 ``` Combine pagination with filters rather than paging through everything. `GET /orders?status=picked,verified` and `GET /orders?has_unmatched_prescriptions=true` will nearly always be faster than draining the full list and filtering client-side. Requesting a `page_size` above 200 does not error — it is clamped to 200. Trust `X-Page-Size` in the response over the value you asked for. Paginated, filterable by status Paginated Paginated, filterable # How does patient messaging work in Blend? Source: https://docs.byblend.com/guides/patient-messaging When a patient replies to a Blend text message, it lands in your Messaging inbox in the Blend Dashboard, with an unread badge and optional webhook or email alerts. You reply within a thread; your team marks your own conversations as read. When a patient replies to a Blend text message (either a shipping confirmation or a refill reminder), it lands in your **Messaging** inbox in the Blend Dashboard — not in a shared queue, and not with Blend staff. Blend matches the inbound message to the patient and routes it to the business that owns them. You'll see two inboxes: **Patients** for active conversations, and **Archive** for ones you've closed out. An unread badge appears in the sidebar and on the Dashboard home page. ## Getting notified Beyond the in-app badge, you can be alerted by **webhook** or **email** when a patient message arrives — useful if your team doesn't live in the Blend Dashboard all day. Set these up alongside your other notification subscriptions; see [webhooks](/guides/webhooks). ## Replying Patient messaging is **reply-only**. You respond within an existing conversation; you can't start a new outbound thread to a patient from the inbox. Conversations begin from patient-facing activity such as shipment notifications. Your team marks your own patient conversations as read. Blend staff can't clear your unread count on your behalf — what's unread in your inbox reflects what your team has actually seen. Replies go out as written. No signature is appended automatically, so include whatever attribution your business wants the patient to see. ## How Blend decides which patient a message is from Inbound messages are matched on phone number. Where a number matches more than one patient record — a shared household phone, a parent managing several children's care — Blend looks for a patient's first or last name in the message text to disambiguate, and otherwise attributes it to the most recently active patient. Read the patient name on the conversation before replying with anything clinical, particularly for shared household numbers. The automatic attribution is a best guess, not a verified identity. ## Patient notification preferences Whether a patient receives messages from Blend at all is controlled per patient by `receive_sms` and `receive_email`: ```json theme={null} { "receive_sms": true, "receive_email": true } ``` These flags only take effect if you have authorized Blend to send patient communications on your behalf. If you haven't, Blend doesn't contact your patients and all patient communication stays with your business. Set them at [patient creation](/guides/create-a-patient) or update them later with `PATCH /patients/{patient_id}`. ## Comments are not patient messages Comments on an order or prescription are the internal channel between your team and Blend pharmacy staff — questions about a stuck order, a replacement decision, a clarification on a prescription. Patients never see them. Anyone who has commented on a thread is notified by email when it's added to, which is how replacement approvals and declines reach the person who asked. Set `receive_sms` and `receive_email` Get alerted when a message arrives Change notification preferences Messaging across a brand's businesses # How do I record a patient's allergies, conditions, and medications? Source: https://docs.byblend.com/guides/patient-risk-factors Send them as freeform text in the risk_factors object at patient creation, or POST to /api/v1/patients/{patient_id}/risk_factors/raw_text later. Blend parses and standardizes the text asynchronously. Blend accepts risk factors as plain text. You don't need to look up codes or match to a controlled vocabulary — send `"peanuts, tree nuts, shellfish"` and Blend parses it, standardizes it, and attaches structured risk factors to the patient. Delimit with commas, semicolons, or slashes. This matters clinically: risk factors drive the drug utilization review that every prescription passes through before it can be filled. A patient record with no allergies recorded is not the same as a patient with no allergies. ## At patient creation ```json theme={null} { "first_name": "Willard", "last_name": "Donnelly", "email": "wdonnelly@example.com", "phone": "6417383445", "date_of_birth": "1990-01-01", "address": { "address_1": "140 Lindgren Street", "city": "Boston", "state": "MA", "zip_code": "02108" }, "risk_factors": { "allergies": "peanuts, tree nuts, shellfish", "conditions": "asthma, hypertension", "medications": "albuterol, levothyroxine" } } ``` ## Adding them later ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/patients/clinic-pt-4471/risk_factors/raw_text \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "allergies": "Penicillin, latex", "conditions": "Asthma, hypertension", "medications": "vyvanse/metformin" }' ``` The path accepts your `external_id` as well as the Blend UUID. **Parsing is asynchronous.** The endpoint returns before the text has been processed into standardized risk factors. If you read the patient's risk factors back immediately, they may not be there yet. Don't build a synchronous write-then-verify loop around this. ## Reading them back ```bash theme={null} curl https://api.byblend.com/api/v1/patients/clinic-pt-4471/risk_factors \ -H "Authorization: Bearer {access_token}" ``` Risk factors come back separated into allergies, conditions, and medications, with the standardized match alongside the original text. ## Removing one Risk factors are deactivated rather than deleted, so the clinical history stays intact: ```bash theme={null} curl -X DELETE https://api.byblend.com/api/v1/patients/{patient_id}/risk_factors/{risk_factor_id} \ -H "Authorization: Bearer {access_token}" ``` Pregnancy, smoking, and diabetes are separate boolean fields on the patient record — `is_pregnant`, `is_smoker`, `is_diabetic` — not risk-factor text. Set them with `POST /patients` or `PATCH /patients/{patient_id}`. Send the patient's medication list even for drugs Blend doesn't dispense. The interaction check is only as good as the medication list it runs against, and your business is usually the only party that knows the full picture. Risk factors are also visible and editable on the patient record in the Blend Dashboard, which is where clinical staff typically review them. POST /patients/patient\_id/risk\_factors/raw\_text Parsed and standardized Soft-delete, history preserved Accepts `risk_factors` inline # How do I pause an order and resume it later? Source: https://docs.byblend.com/guides/pause-an-order PUT /api/v1/orders/{order_id}/pause holds an order indefinitely. PUT /orders/{order_id}/pause/{YYYY-MM-DD} holds it until a date and then auto-unpauses. PUT /orders/{order_id}/unpause resumes it and restores the prior status. Pausing holds an order in place without cancelling it. Use `PUT /api/v1/orders/{order_id}/pause` for an indefinite hold, or `PUT /api/v1/orders/{order_id}/pause/{date}` to hold until a calendar date, at which point the order unpauses itself. Both are valid only from `received` or `exception`. ```bash theme={null} # Hold indefinitely curl -X PUT https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/pause \ -H "Authorization: Bearer {access_token}" # Hold until September 15 curl -X PUT https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/pause/2026-09-15 \ -H "Authorization: Bearer {access_token}" ``` ## Resuming ```bash theme={null} curl -X PUT https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/unpause \ -H "Authorization: Bearer {access_token}" ``` Unpausing restores the order's **prior status** and clears `paused_until`. It's valid only from `paused`. ## How the timed pause behaves * The order **automatically unpauses** when that date arrives — you don't need to call anything. * `paused_until` is `null` when the pause is indefinite, or when the order isn't paused. * Calling pause-until again on an already-paused order **updates** the date rather than erroring. A date in the past, or a format other than `YYYY-MM-DD`, returns a `400`. ## What pausing does and doesn't do Pausing stops fulfillment. It does not cancel the order, release the prescription's fills, or notify the patient. The order retains its line items and its prescription links, and picks up exactly where it left off. Pausing an order is different from a prescription being **too early to fill**. That's an automatic hold Blend applies based on the patient's remaining supply, and it resolves on its own — see [stuck orders](/guides/stuck-orders). Indefinite hold Auto-unpauses on the date Restores the prior status When it shouldn't ship at all # Does Blend track prescriber license status for me? Source: https://docs.byblend.com/guides/prescriber-license-monitoring Yes, wherever it can. Blend auto-populates prescriber records from the national NPI registry, sweeps the DEA registry on a recurring basis for expired or inactive registrations, and holds orders when the prescriber isn't licensed in the state that matters. Blend actively maintains prescriber credential data rather than treating it as static text you typed once. Records are populated from the national NPI registry, DEA registrations are checked against the federal registry on a recurring schedule, and state license coverage is evaluated at fill time — so an order does not ship against a prescriber who isn't properly licensed for that patient. You remain responsible for supplying and renewing state licenses. Blend's job is to catch what's missing, expired, or inconsistent before it becomes a compliance problem. ## What Blend maintains automatically Prescriber demographics and professional credentials are pulled from the national NPI registry, so names, credential types, and practice details come from the authoritative source rather than manual entry. Blend sweeps the federal DEA registry on a recurring schedule, flagging registrations that are expired, inactive, or absent from the registry entirely. At fill time, Blend checks that the prescriber holds a valid license covering the patient's state. If not, the order is held rather than shipped. Blend predicts when each prescription is next due and warns when the covering license expires before then — see [refill risk](/guides/refill-risk). ## What that means day to day **Orders hold instead of shipping.** If a prescriber's license is missing or expired for the relevant state, the order moves to `exception` rather than going out the door. Supply or renew the license and the order releases automatically — no need to ask for a re-check. See [stuck orders](/guides/stuck-orders). **Credential problems surface before a fill is due.** Rather than discovering an expired DEA registration when an order stalls, the recurring registry sweep raises it in advance. **Duplicate manual entry is reduced.** Because prescriber records draw on the NPI registry, you generally don't need to key in credential details that are already public record. ## What you still need to supply **State licenses are yours to provide and renew.** Blend cannot obtain state board licenses on your behalf — there is no single national source for them. Add and renew them through the API or the Blend Dashboard; see [keeping prescriber state licenses current](/guides/prescriber-licenses). Also yours: which prescribers belong to your account, any prescribing `restrictions` you want enforced, and supervisory relationships where a prescriber practises under supervision. ## Checking status yourself ```bash theme={null} # Everything on file for a prescriber, by NPI curl https://api.byblend.com/api/v1/prescribers/1234567890 \ -H "Authorization: Bearer {access_token}" # Which prescriptions are at licensing risk right now curl "https://api.byblend.com/api/v1/prescriptions?refill_risk=true&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` The second call is the one worth running on a schedule. It returns `at_risk`, a reason code of `prescriber_unlicensed` or `prescriber_license_expiring`, and the dates behind the judgment — enough to build a prioritized renewal worklist. Prescriber records, licenses, and credential status are all visible in the Blend Dashboard under Prescribers. For compliance staff who don't work in the API, that's the day-to-day surface. Licenses, credentials, restrictions `refill_risk=true` Add or renew a state license Audit your full roster # How do I keep prescriber state licenses current? Source: https://docs.byblend.com/guides/prescriber-licenses POST /api/v1/prescribers/{prescriber_id}/qualifications to add a state license. Updating a state's license with a new number automatically deactivates the old one. You can address a license by state abbreviation instead of its UUID. A prescription can only be filled if the prescriber holds a valid license covering the relevant state. Add licenses with `POST /api/v1/prescribers/{prescriber_id}/qualifications`, giving at minimum a `state` and a `license_number`. Expired or missing licenses are one of the most common reasons an order gets stuck, so keeping this current is worth automating. ## Add a license ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/prescribers/1234567890/qualifications \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "state": "OH", "license_number": "35-098765", "description": "Nurse Practitioner, Family", "expiration_date": "2027-03-15" }' ``` The prescriber path accepts a UUID or a 10-digit NPI. ## Renew one without knowing its ID Blend accepts a **two-letter state abbreviation** wherever a qualification UUID is expected, which resolves to that state's currently-active license: ```bash theme={null} curl -X PUT https://api.byblend.com/api/v1/prescribers/1234567890/qualifications/OH \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "state": "OH", "license_number": "35-098765", "expiration_date": "2029-03-15" }' ``` This means a renewal script needs only the NPI and the state — no Blend identifiers at all. **Updating a state's license with a new number automatically deactivates the old one.** You don't need to deactivate the previous license first; the history is retained. `DELETE` on a qualification **deactivates** it rather than removing it. Licensing history is preserved for compliance, so a deactivated license still appears in the record. ## See what's on file ```bash theme={null} curl https://api.byblend.com/api/v1/prescribers/1234567890 \ -H "Authorization: Bearer {access_token}" ``` The prescriber record returns `qualifications`, `credentials`, `addresses`, and `restrictions` together. ## Catching expiries before they cause a problem Auditing expiration dates tells you which licenses lapse soon. It doesn't tell you which ones **matter** soon. [Refill risk](/guides/refill-risk) does — it compares each prescriber's license coverage against the predicted next fill date for each prescription: ```bash theme={null} curl "https://api.byblend.com/api/v1/prescriptions?refill_risk=true" \ -H "Authorization: Bearer {access_token}" ``` A license expiring in three months is irrelevant if no fill is due; one expiring next week against a fill due Tuesday is urgent. Sort by `days_until_next_fill`, not by expiration date. Blend also monitors prescriber credentials independently and flags problems it finds — see [does Blend track prescriber license status for me?](/guides/prescriber-license-monitoring). Licenses are editable in the Blend Dashboard under Prescribers, which is where most compliance staff work. POST .../qualifications Accepts a state abbreviation Soft-delete, history kept All licenses and credentials # How does Blend match a prescription to a patient, product, and order? Source: https://docs.byblend.com/guides/prescription-matching Blend matches patients on external_id or Blend id when sent via API, and on name plus date of birth from Surescripts. Products match on product_code, then sku, then name, then NDC. Orders inherit the patient match. Blend resolves three links for every inbound prescription: which patient it belongs to, which of your products it refers to, and which order it should fill. Each uses a different set of signals, and each degrades gracefully — an unmatched prescription waits rather than failing. ## Prescription to patient * **Sent via API** — Blend looks for the patient's `id` (Blend UUID) or `external_id` (your identifier, stored on the Blend patient profile). This is definitive. * **Sent via Surescripts** — Blend matches on patient name (or preferred name) and date of birth, or on patient contact information and date of birth. Only **definitive** matches are assigned automatically. Blend deliberately does not auto-assign a "possible" match — an ambiguous prescription waits for a human rather than attaching to the wrong chart. ## Prescription to prescriber Prescribers are matched on **NPI** or **DEA number**. ## Prescription to product Blend works from highest confidence to lowest: 1. `product_code` — your prescription-product code 2. `sku` — your inventory identifier 3. Product name 4. NDC, including NDCs related through RxNorm 5. Drug name, with common abbreviations normalized before comparison 6. Parsing the SCRIPT `` field 7. Parsing the `` field For Surescripts prescriptions specifically, Blend parses ``, ``, and `` looking for your products' `sku`, `product_code`, `id`, or `name`. ## Prescription to order Because an order always carries a patient, Blend uses the patient match to tie orders and prescriptions together. Among the prescriptions eligible for an order line, a candidate must be: * not cancelled, * have fills remaining, and * not expired. Where several candidates qualify, **the newest prescription wins**, ordered by `written_at` and then by creation time. **A newer prescription can supersede an older one on an open order.** When a fresh prescription arrives for the same patient and product, Blend re-links the order line to it — but only while the order is in `received`, `exception`, or `paused`. Once an order is picked or verified, its prescription links are fixed. ## Helping the match along When you already know which prescriptions belong to an order, name them explicitly at creation time: ```json theme={null} { "patient": { "external_id": "clinic-pt-4471" }, "electronic_prescription_ids": [ "BFCB96C9-F866-405E-A1B3-3ED031DFB423" ], "products": { "prescription": [{ "product_code": "HC-RAPA31", "quantity": 1 }] } } ``` `electronic_prescription_ids` is an optional convenience field that removes any ambiguity about which prescription an order should draw from. Blend staff can also map a prescription by hand when an inbound message needs human judgment — a misspelled name from the prescriber, or a transfer that arrived with partial data. If a prescription you sent hasn't matched, Blend will typically find and address it. The canonical field-level rules Accepts `electronic_prescription_ids` Filter by patient, product, prescriber `has_unmatched_prescriptions=true` # How do I reference my own products in Blend? Source: https://docs.byblend.com/guides/reference-your-products Use the Blend product id, your own sku, or — for prescription products only — your product_code. Map these during onboarding and your system never has to store Blend UUIDs. Every product reference in the Blend API accepts three forms of identifier, and you choose which to use: * **`id`** — the Blend product UUID * **`sku`** — your own inventory identifier * **`product_code`** — your own code, **prescription products only** Map `sku` and `product_code` onto your Blend products during onboarding and your integration can speak entirely in your own vocabulary. ## Which identifier goes where | Product type | `id` | `sku` | `product_code` | | - | :-: | :-: | :-: | | Prescription products | Yes | Yes | Yes | | Non-prescription products | Yes | Yes | No | | Order materials | Yes | Yes | No | `product_code` is available on **prescription products only**. Referencing a non-prescription product or an order material by `product_code` will not resolve — use `sku`. ## In an order ```json theme={null} { "patient": { "external_id": "clinic-pt-4471" }, "products": { "prescription": [ { "product_code": "HC-RAPA31", "quantity": 1 } ], "non_prescription": [ { "sku": "SHARPS-SM", "quantity": 1 } ], "order_material": [ { "sku": "COLDPACK-2", "quantity": 1 } ] } } ``` Send exactly one identifier per line item — `id`, `sku`, or `product_code`, not several. ## In a prescription `product_code` is a shorthand helper to assist with matching from SCRIPT XML. Blend looks for `product_code` (and `sku`, product `id`, and `name`) in the ``, ``, and `` XML fields. ```json theme={null} "medication": { "product_code": "HC-RAPA31", "drug_name": "Rapamycin", "quantity": 30, "units": "C48480" } ``` Getting `product_code` right is the highest-leverage mapping you can do. It's the top of Blend's product-matching order and eliminates the guesswork of drug-name and description parsing — see [how matching works](/guides/prescription-matching). ## Setting the mapping ```bash theme={null} curl -X PATCH https://api.byblend.com/api/v1/products/prescription/98cae3a3-996c-4bf5-9143-0ab6d98bc1d0 \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "sku": "MY-SKU-1234567890", "product_code": "SUPERSPRAY15" }' ``` This is a partial update — send only what's changing. Non-prescription products and order materials have their own equivalent endpoints. ## Listing what's available ```bash theme={null} # Everything, in separate arrays by type curl https://api.byblend.com/api/v1/products \ -H "Authorization: Bearer {access_token}" # Just one type curl "https://api.byblend.com/api/v1/products?type=prescription" \ -H "Authorization: Bearer {access_token}" ``` `type` accepts `prescription`, `non_prescription`, or `order_material`. There are also dedicated endpoints per type. Blend sets up your initial catalog and maps it to your EMR or inventory system during onboarding — you shouldn't need to map products one at a time to get started. Your product catalog is viewable in the Blend Dashboard under Products. All types, or filter with `type=` Set `sku` and `product_code` Just prescription products By name or SKU # What is refill risk, and how do I check it? Source: https://docs.byblend.com/guides/refill-risk Refill risk compares a prescriber's license coverage against the predicted next fill date. Pass refill_risk=true on GET /prescriptions, GET /prescriptions/{id}, or GET /patients/{id}/prescriptions to get the assessment. Refill risk answers a specific question: when this prescription next comes up for a fill, will the prescriber still be licensed in the state that matters? Blend predicts the next fill date from the last fill and the days supply, then checks the prescriber's state licenses against it. Add `refill_risk=true` to any prescriptions request and each prescription comes back with a nested `refill_risk` object. It's a forward-looking check, not a status. A prescription can be perfectly valid today and still be at risk, because the license covering it expires before the patient is due for their next fill. ## Ask for the assessment ```bash theme={null} curl "https://api.byblend.com/api/v1/prescriptions?refill_risk=true&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` The same parameter works on a single prescription and on a patient's prescriptions: ```bash theme={null} curl "https://api.byblend.com/api/v1/patients/clinic-pt-4471/prescriptions?refill_risk=true" \ -H "Authorization: Bearer {access_token}" ``` The `refill_risk` object is **omitted entirely** unless you pass the parameter. Don't write code that expects it on every prescription response. ## Reading the result `at_risk` is the field to alert on. It's `true` when the covering license is missing today, or expires before the predicted next fill. When `at_risk` is true, `reasons` tells you which: | Reason code | Meaning | | - | - | | `prescriber_unlicensed` | No valid license covering the relevant state today | | `prescriber_license_expiring` | Licensed now, but expires before the predicted next fill | The assessment also returns `predicted_next_fill_date`, `last_fill_date`, `days_supply_used`, `relevant_states`, `covering_licenses`, `earliest_covering_expiration`, `days_until_next_fill`, and `days_until_license_expiry` — enough to build a prioritized worklist rather than a flat alert. ## When it doesn't apply `applicable: false` means Blend skipped the assessment, and `not_applicable_reason` says why: * `cancelled` — the prescription is cancelled * `rx_expired` — the prescription has already expired * `no_fills_remaining` — nothing left to fill * `no_prescriber` — no prescriber attached * `no_relevant_states` — no state could be determined to check against These are not problems to fix. A cancelled prescription has no next fill to be at risk for. Run this weekly across your active prescriptions and sort by `days_until_next_fill`. A license expiring in 90 days matters far less than one expiring before a fill that's due next week. Refill risk is a licensing check, not a clinical or timing one. It won't tell you whether a refill is too early to fill, or whether the prescription itself is close to expiring — check `expires_at` and `fills_remaining` on the prescription for those. ## Fixing what it finds The remedy is almost always to update the prescriber's state license. Add or renew one with `POST /prescribers/{prescriber_id}/qualifications`, or manage licenses directly in the Blend Dashboard under Prescribers. Blend also monitors prescriber credentials on your behalf — see [does Blend track prescriber license status for me?](/guides/prescriber-license-monitoring) `refill_risk=true` `refill_risk=true` Add a state license Current licenses and credentials # How do I request a replacement order? Source: https://docs.byblend.com/guides/replacement-orders PUT /api/v1/orders/{order_id}/request_replacement with a reason. Blend creates a brand-new order linked to the original, and it does not consume a fill from the prescription. A replacement is a genuinely new order — its own order number, its own lifecycle — with two differences from an ordinary one: it carries a link back to the order it replaces, and **it does not decrement fills** on the underlying prescription. A patient whose shipment arrived damaged doesn't lose a refill because of it. ```bash theme={null} curl -X PUT https://api.byblend.com/api/v1/orders/ORD250312003548IAU4/request_replacement \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "reason": "Product arrived damaged" }' ``` The `reason` reaches the pharmacy staff who fulfil the request, so make it specific — "damaged in transit, vial cracked" is more actionable than "problem". ## Tracking the request The order object carries the full replacement picture: | Field | What it tells you | | - | - | | `replacement_request_status` | `pending`, `fulfilled`, `declined`, or `cancelled` | | `replacement_requested_at` | When the request was raised | | `replacement_requested_reason` | The reason you sent | | `replacement_order_ids` | The new orders created from this one | | `is_replacement` | True on the replacement order itself | | `original_order_id` | On the replacement, points back to the original | ## Finding the replacement order Once created, the replacement is visible immediately — you don't need to wait for anyone to send you the number. Poll the original order and read `replacement_order_ids`, or find it in the Blend Dashboard on the orders list, filtered to your account. It also appears on the patient's order history. Approvals and declines are recorded as comments on the replacement thread, and anyone who has previously commented on that thread is notified by email. If a request is declined, the reason reaches the requester through that channel. ## What a replacement doesn't do A replacement also doesn't cancel or reverse the original order. The original keeps its own status and history; the two are linked, not merged. ## Replacement, cancellation, or a new order? * Shipment was wrong or damaged, patient should not lose a fill → **replacement** * Order shouldn't ship at all and hasn't been picked → [cancel](/guides/cancel-an-order) * Order shouldn't ship yet → [pause](/guides/pause-an-order) * Patient wants more product and has fills remaining → an ordinary new order PUT /orders/order\_id/request\_replacement Read `replacement_request_status` Find replacements across your account When it shouldn't ship instead # What reports can I pull from the Blend API? Source: https://docs.byblend.com/guides/reports GET /api/v1/reports/daily returns daily counts of new patients, prescriptions, and orders. GET /api/v1/reports/orders returns orders by date range and status. Both are date-ranged and scoped to your account. Blend exposes two reporting endpoints for pulling operational counts into your own systems. **`GET /api/v1/reports/daily`** — daily counts of new patients, prescriptions, and orders. Defaults to the past 14 days; maximum range 365 days. **`GET /api/v1/reports/orders`** — orders grouped by status over a date range you specify. For a richer, interactive view — turnaround times, invoicing, utilization by prescriber — see the [Metrics report](/guides/metrics-report) in the Blend Dashboard. ## Daily counts ```bash theme={null} curl "https://api.byblend.com/api/v1/reports/daily?start_date=2026-08-01&end_date=2026-08-23&timezone=America/New_York" \ -H "Authorization: Bearer {access_token}" ``` * `start_date` / `end_date` — optional. Omit both for the past 14 days. Maximum range is 365 days. * `timezone` — an IANA name such as `America/New_York`, used for day grouping. **Defaults to UTC.** Set `timezone` explicitly if your business day isn't UTC. Without it, a late-afternoon order on the US West Coast lands on the following day's count, and your daily numbers won't reconcile with what your team saw. **Cancelled prescriptions and orders are excluded** from these counts, and transfers are counted separately from prescriptions. These are counts of real activity, not of records created. ## Orders by status ```bash theme={null} curl "https://api.byblend.com/api/v1/reports/orders?start_date=2026-08-01&end_date=2026-08-31&include=status,count" \ -H "Authorization: Bearer {access_token}" ``` `start_date` and `end_date` are **required** here. `include` selects which fields come back — `status`, `count`, `products`, comma-separated. Ask only for what you need; `products` is substantially heavier. ## Building your own The reporting endpoints are deliberately narrow. For anything else, the list endpoints with filters plus [pagination](/guides/pagination) will get you there: ```bash theme={null} # Everything shipped in a window, drained page by page curl "https://api.byblend.com/api/v1/orders?status=shipped&page_size=200" \ -H "Authorization: Bearer {access_token}" # Prescriptions with no order attached curl "https://api.byblend.com/api/v1/prescriptions?has_order=false&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` For a running operational feed, [webhooks](/guides/webhooks) beat polling a report. Subscribe to `order.shipped` and `order.delivered` and build your own daily rollup from events as they land. Patients, prescriptions, orders per day Orders by status and date range Turnaround, invoicing, utilization Filter and page for custom reporting # How do I search across Blend? Source: https://docs.byblend.com/guides/search GET /api/v1/search spans orders, patients, prescribers, and products in one call, with ranked results. Scoped variants like /search/patients narrow to a single type. `GET /api/v1/search` searches orders, patients, prescribers, and products in a single request. Results are ranked and each carries a `result_type` so you can tell what you matched. Searchable fields include IDs, order numbers, names, emails, phone numbers, prescriber identifiers, product names, and SKUs — with substring matching across all of them. ```bash theme={null} curl "https://api.byblend.com/api/v1/search?q=donnelly&limit=50" \ -H "Authorization: Bearer {access_token}" ``` `limit` defaults to 50 and maxes at 100. ## Exact phrases Wrap the phrase in URL-escaped quotes to match it exactly rather than as loose terms: ```bash theme={null} curl "https://api.byblend.com/api/v1/search?q=%22Joe%20Public%22" \ -H "Authorization: Bearer {access_token}" ``` ## Searching one type When you know what you're looking for, the scoped endpoints are faster and return less noise: | Endpoint | Searches | | - | - | | `/api/v1/search/orders` | Orders | | `/api/v1/search/patients` | Patients | | `/api/v1/search/prescribers` | Prescribers | | `/api/v1/search/products` | Products | Patient search accepts a date of birth in `MM/DD/YYYY`, `YYYYMMDD`, or `YYYY-MM-DD` — you don't have to normalize the format your users type. ## Search versus filtered lists Search is for **finding a known thing** when you have a fragment of it — a partial name, a phone number, half an order number. It is not the tool for enumerating a set. For "every order that shipped last week" or "every prescription without an order", use the list endpoints with filters and [pagination](/guides/pagination): ```bash theme={null} curl "https://api.byblend.com/api/v1/orders?status=shipped&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` Those are exhaustive and paginated. Search is ranked and capped at 100 results, so it will quietly miss things if you use it as a list. Searching for a prescription that never matched a patient is a different problem — an unmatched inbound message may not surface where you expect. See [why Blend can't find a prescription I sent](/guides/find-a-missing-prescription). GET /search Accepts several DOB formats By order number or external ID By name or SKU # Can I send an electronic prescription to Blend directly? Source: https://docs.byblend.com/guides/send-electronic-prescription Yes — POST /api/v1/prescriptions/electronic_prescriptions with NCPDP SCRIPT XML or JSON. This is an alternative to Surescripts, available for non-controlled substances only at this time. Yes. Sending prescriptions directly to Blend over the API is an alternative to routing them through Surescripts, and is available for **non-controlled substances only** at this time. Post to `/api/v1/prescriptions/electronic_prescriptions` with either NCPDP SCRIPT XML (`application/xml`) or a JSON body. In JSON you supply a `patient`, a `prescriber`, and either a single `medication` or an array of `medications`. Blend then matches the prescription to a patient, a prescriber, and one of your products — you do not have to resolve those links yourself. A prescription can be sent before or after the patient and the order exist. Blend matches whenever the data is available, so ordering is not a constraint. ## Send one prescription ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/prescriptions/electronic_prescriptions \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "patient": { "external_id": "clinic-pt-4471" }, "prescriber": { "id": "0227d1e5-ba9a-42b5-8fe2-38882aa65708" }, "medication": { "product_code": "HC-RAPA31", "drug_name": "Rapamycin", "quantity": 30, "units": "C48480", "days_supply": 30, "refills": 4, "sig": "Take one capsule by mouth once weekly", "written_at": "2026-08-20T00:00:00" } }' ``` Key fields: * **`product_code`** — your own code for the prescription product. Send this or `prescription_product_id` (the Blend UUID); you don't need both. * **`units`** — an NCPDP quantity-unit code, not a word. `C48480` is Capsule, `C48542` is Tablet, `C28253` is Milligram. Pull the full list from `GET /prescriptions/quantity_units`, which returns each `code` alongside its `term` and definition. * **`patient`** — reference an existing patient by `id` or `external_id`, or pass a full new-patient object to create one inline. * **`medications`** — use the array form when one prescription carries several drugs; each becomes its own prescription in Blend. ## Sending SCRIPT XML instead If you already generate NCPDP SCRIPT, post the raw XML with `Content-Type: application/xml`. Blend parses ``, ``, and `` looking for matches against your products' `product_code`, `sku`, `id`, or `name`. ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/prescriptions/electronic_prescriptions \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/xml" \ --data-binary @newrx.xml ``` ## Attaching it to an order An order can be created before or after the prescription. If the order already exists, pass its `id` or `order_number` in the `order` object. If it doesn't, create it afterwards with `POST /orders` and optionally list the prescription in `electronic_prescription_ids` to help matching along. To do all of it in one request, use the [composite endpoint](/guides/composite-creation). POST /prescriptions/electronic\_prescriptions Valid NCPDP `units` codes Add `include_xml=true` for raw SCRIPT Prescription + order in one call # How do I choose the carrier, service level, and signature confirmation on an order? Source: https://docs.byblend.com/guides/shipping-preferences Send a shipping object with carrier, service_level, and signature_confirmation on POST /orders or PATCH /orders/{order_id}. Use a generic service level to let Blend pick the carrier, or name both. Pass a `shipping` object when you create or update an order. You can specify a `carrier` (`ups`, `usps`, `fedex`), a `service_level`, a `signature_confirmation` (`standard` or `adult`), or any combination. Give a generic service level on its own — `ground`, `2_day`, `next_day` — and Blend selects the most appropriate carrier to meet it. ```json theme={null} { "patient": { "external_id": "clinic-pt-4471" }, "shipping": { "carrier": "usps", "service_level": "usps_ground_advantage", "signature_confirmation": "adult" }, "products": { "prescription": [{ "product_code": "HC-RAPA31", "quantity": 1 }] } } ``` Shipping preferences need to be enabled for your account. Confirm with your Blend contact before building against them. ## Service levels | Carrier | Service levels | | - | - | | USPS | `usps_ground_advantage`, `usps_priority`, `usps_priority_express` | | FedEx | `fedex_ground`, `fedex_2_day`, `fedex_express_saver`, `fedex_standard_overnight`, `fedex_priority_overnight`, `fedex_first_overnight` | | UPS | `ups_ground`, `ups_second_day_air`, `ups_3_day_select`, `ups_next_day_air`, `ups_next_day_air_saver` | | Generic | `ground`, `2_day`, `next_day` | If you send **both** `carrier` and `service_level`, the service level's prefix must match the carrier. `carrier: "usps"` with `service_level: "fedex_ground"` is rejected. Send the generic level alone if you don't care which carrier is used. `GET /api/v1/orders/shipping_options` returns the carriers and service levels currently available to your account — read it rather than hardcoding this table. ## Signature confirmation * `standard` — anyone at the address may sign * `adult` — signature from someone 21 or over ## Updating shipping later ```bash theme={null} curl -X PATCH https://api.byblend.com/api/v1/orders/ORD250312003548IAU4 \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "shipping": { "service_level": "next_day" } }' ``` Update semantics are worth reading twice: * Omitted fields are **left unchanged**. * Send `"signature_confirmation": null` to **clear** a previously set signature preference. * Sending `carrier` or `service_level` **does not** clear an existing signature preference. Shipping stays editable later in the order's life than line items do — a label hasn't been purchased yet at `picked` or `verified`. Once an order is `shipped` or `delivered`, shipping is fixed and the order returns tracking information instead. ## Bringing your own label If you generate labels yourself, send `custom_shipping` instead of `shipping`. Bringing your own shipping label is only available to pre-authorized accounts. Talk to your Blend contact before building against it. All four fields are required: `label_url` (a printable 4x6), `tracking_number`, `tracking_url`, and `carrier`. ```json theme={null} { "custom_shipping": { "label_url": "https://yourcompany.com/labels/abc.pdf", "tracking_number": "1Z999AA10123456784", "tracking_url": "https://ups.com/track?tracknum=1Z999AA10123456784", "carrier": "UPS" } } ``` Shipping preferences on an individual order can also be changed in the Blend Dashboard while the order is still editable — a quicker path for a single customer-service request than an API call. Live carriers and service levels PATCH the `shipping` object `shipping` or `custom_shipping` Shipments and tracking # Why is my order stuck, and what do I do about it? Source: https://docs.byblend.com/guides/stuck-orders An order in exception status is blocked by something — a missing prescription, an expired prescriber license, missing patient ID. Most clear automatically once the data arrives, and the order returns to where it was in the queue. An order enters `exception` status — "stuck" — when something blocks fulfillment. It steps out of the queue and returns to exactly where it was once the blocker clears. It is not cancelled, and its place in line is preserved. Most stuck reasons resolve **automatically**. If the blocker is missing data, supplying that data is the entire fix; Blend re-evaluates and releases the order without anyone clicking anything. ## Find your stuck orders ```bash theme={null} curl "https://api.byblend.com/api/v1/orders?status=exception&page_size=200" \ -H "Authorization: Bearer {access_token}" ``` ## Reasons that clear themselves | Blocker | What clears it | | - | - | | Missing prescription | The prescription arrives and matches | | Prescription expired or out of fills | A new prescription arrives | | Prescriber license expired or missing | The license is updated in Blend | | Missing patient driver's license or SSN | The value is added to the patient record | You don't need to ask for a re-check. Blend re-evaluates these conditions on its own and releases the order. Supplying the data **is** the action. ## Reasons that need a decision Some exceptions are clinical or commercial judgments rather than missing fields — a possible duplicate order, a refill arriving earlier than the patient's supply should allow, a product that couldn't be matched. These are worked by pharmacy staff, and often need a conversation with you. You can have that conversation over the API or in the Blend Dashboard. In the Blend Dashboard, stuck orders have their own queue with the reason and any staff commentary attached. For non-technical team members that's the place to work from. Responses posted over the API show up in the same discussion. ## Respond to a stuck order In an `order.stuck` webhook, `id` is not the exception. Like every `order.*` webhook, `id` identifies the stuck item, and `entity_type` says what kind of item it is: * `entity_type: "order"`: `id` is the order ID. * `entity_type: "prescription"`: `id` is the prescription ID. The exception itself is `exception_id`. Use it to read or respond to the exception. Read the exception and its discussion so far: ```bash theme={null} curl "https://api.byblend.com/api/v1/exceptions/entity/order/{order_id}?include_responses=true" \ -H "Authorization: Bearer {access_token}" ``` `{order_id}` accepts the order's UUID, order number, or your external ID. For an order, the list also includes exceptions on the order's prescriptions. Reply on a specific exception, with the name of the person responding: ```bash theme={null} curl -X POST "https://api.byblend.com/api/v1/exceptions/{exception_id}/responses" \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{"text": "Corrected shipping address is on the order now.", "first_name": "Charlie", "last_name": "Customer"}' ``` `first_name` and `last_name` are required, at least 2 characters each. For regulatory purposes, Blend must identify and keep a record of the authorized person behind every response. API credentials are usually shared by a team, so the account alone doesn't say who that is. Blend appends the name to the end of the response, as `[Response from: Charlie Customer]`. A response puts the exception back in front of the pharmacy team, including an exception they had set aside to revisit later. It does not resolve the exception; that still happens when Blend clears it or the missing data arrives. When Blend replies, you receive an `order.stuck_response` webhook. Its `id`, `entity_type`, and `exception_id` mean the same as in `order.stuck` and have the same values, so `id` is still the order or prescription, not the exception or the response. The reply itself is in `response`, with its own `response.id`. Subscribe to it alongside `order.stuck` to keep the conversation in your own system. With `include_responses=true` Reply to Blend By `exception_id` `status=exception` When it stuck and when it cleared Find unmatched prescriptions What `exception` means in context # How do I transfer a prescription out to another pharmacy? Source: https://docs.byblend.com/guides/transfer-out The receiving pharmacy requests the transfer from Blend directly — by email at support@byblend.com, by phone at (800) 292-0499, or by fax at (380) 215-3850. Blend handles the transfer and cancels the prescription once it's complete. Transfers out are initiated by the **receiving pharmacy**, not by you and not in the Blend Dashboard. The destination pharmacy contacts Blend directly and requests the transfer: [support@byblend.com](mailto:support@byblend.com) (800) 292-0499 (380) 215-3850 Blend handles the transfer digitally from there, and **cancels the prescription in Blend once it has been transferred**. That cancellation is the expected end state — the receiving pharmacy now holds the prescription, so it must not remain fillable at Blend. ## What you need to do Nothing, in most cases. If a patient tells you they want their prescription moved to another pharmacy, direct them — or the receiving pharmacy — to the contact details above. Check for open orders before a transfer is requested. Transferring cancels the prescription, but an order already in the pharmacy is a separate object with its own lifecycle — [cancel or pause it](/guides/cancel-an-order) explicitly if it shouldn't ship. ## Confirming the outcome ```bash theme={null} curl https://api.byblend.com/api/v1/prescriptions/{prescription_id} \ -H "Authorization: Bearer {access_token}" ``` A transferred prescription reads as cancelled. Cancelled prescriptions are excluded from all matching, so a transferred prescription can't be picked up by a future order. **A cancelled prescription cannot be un-cancelled through the API.** There is no reversal endpoint. If a transfer was requested in error, contact Blend support — and expect the practical remedy to be a new prescription from the prescriber. Confirm status after transfer Filter by status Deal with open orders first What happens to orders in flight # How do I get notified when an order ships? Source: https://docs.byblend.com/guides/webhooks Subscribe a webhook endpoint with POST /api/v1/notifications/webhooks, passing the event codes you care about — order.shipped, order.delivered, or 'all'. Blend POSTs to your URL, and can sign each delivery with an optional webhook secret. Blend pushes events to your systems over webhooks. Create a subscription with `POST /api/v1/notifications/webhooks`, giving it your HTTPS URL and a list of `event_codes` such as `order.created`, `order.shipped`, or `order.delivered`. Pass `"all"` to receive everything. You can optionally generate a webhook secret, and Blend will sign every delivery so you can verify it came from Blend. Webhooks are managed through the API. There is not yet a way to create or edit webhook subscriptions in the Blend Dashboard. ## Set it up ```bash theme={null} curl https://api.byblend.com/api/v1/notifications/events \ -H "Authorization: Bearer {access_token}" ``` Each event returns a `name`, `description`, and the `event_code` you subscribe with. ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/notifications/webhook-secret \ -H "Authorization: Bearer {access_token}" ``` Optional, but recommended. If you generate one, Blend sends it as `Authorization: Bearer {secret}` on every webhook delivery, so you can verify the request came from Blend. Without a secret, deliveries are unsigned. ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/notifications/webhooks \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "url": "https://yourcompany.com/hooks/blend", "event_codes": ["order.shipped", "order.delivered"] }' ``` ```bash theme={null} curl -X POST https://api.byblend.com/api/v1/notifications/sample \ -H "Authorization: Bearer {access_token}" \ -H "Content-Type: application/json" \ -d '{ "event_code": "order.shipped", "webhook_url": "https://yourcompany.com/hooks/blend" }' ``` This delivers a real, illustrative payload to your endpoint. To inspect the shape without sending anything, use `GET /notifications/sample/{event_code}`. ## What your endpoint has to do Blend requires your listener to be a valid SSL endpoint that accepts `POST` and returns a `2xx` status code **within 10 seconds**. Do your real work asynchronously — acknowledge first, process after. Deliveries that fail are retried with exponential backoff. Every payload carries at minimum an `id` and a `url` that deep-links to the relevant record in the Blend Dashboard, so a notification can be turned into a clickable link for your staff with no extra lookup. Prefer webhooks over polling. If you do poll, filtered list calls (`GET /orders?status=shipped`) are much cheaper than draining the full order list — see [pagination](/guides/pagination). ## Email instead of (or alongside) webhooks If a human needs to know rather than a system, subscribe to the same event codes by email with `PUT /api/v1/notifications/email`. Email notifications go to the address on your Blend user profile. POST /notifications/webhooks GET /notifications/events POST /notifications/webhook-secret POST /notifications/sample # Can I use my own IDs instead of Blend IDs? Source: https://docs.byblend.com/guides/your-own-ids Yes. Blend accepts your external_id for patients and orders, and your sku or product_code for products. You do not have to store Blend UUIDs to use the Blend API. Almost every path parameter and product reference accepts your own identifier as an alternative, so your system can stay the source of truth for IDs. Set `external_id` when you create a patient or an order, map your `sku` and `product_code` onto Blend products during onboarding, and you can address Blend resources entirely in your own vocabulary. ## What each resource accepts | Resource | Blend identifier | Your identifier | Also accepted | | - | - | - | - | | Patient | `id` (UUID) | `external_id` | — | | Order | `id` (UUID) | `external_id` | `order_number` (e.g. `ORD250312003548IAU4`) | | Product | `id` (UUID) | `sku` | `product_code` (prescription products only) | ## Fetch an order by your own ID ```bash theme={null} curl https://api.byblend.com/api/v1/orders/my-system-128318AA2 \ -H "Authorization: Bearer {access_token}" ``` The same path position accepts a Blend UUID or the human-friendly order number — you don't need separate code paths for each. ## Set your IDs at creation time ```json theme={null} { "external_id": "my-system-128318AA2", "patient": { "external_id": "clinic-pt-4471" }, "products": { "prescription": [ { "product_code": "HC-RAPA31", "quantity": 1 } ], "non_prescription": [ { "sku": "SHARPS-SM", "quantity": 1 } ] } } ``` A patient's `external_id` is also used for prescription matching. When you send an electronic prescription referencing `external_id`, Blend links it to the right patient without a name-and-date-of-birth lookup — which is the most reliable matching path available. See [how Blend matches prescriptions to patients](/overview#prescription-to-patient). `sku` and `product_code` are not interchangeable. Non-prescription products and order materials can be referenced by Blend `id` or `sku` only; `product_code` is available for **prescription products**. You can set or change `external_id` on an existing order with `PATCH /orders/{order_id}` — useful when your own record is created after the order reaches Blend. External IDs are editable in the Blend Dashboard. Accepts UUID, order number, or external ID Accepts UUID or external ID Set your sku and product\_code # Licensing Source: https://docs.byblend.com/licensing Blend holds an active pharmacy license in all 50 U.S. states and the District of Columbia. Every license includes controlled-substance authority. Blend is a 503A compounding pharmacy licensed to dispense and ship into **all 50 U.S. states and the District of Columbia** — 51 jurisdictions. Every license below is active, and includes the ability to ship controlled substances (when prescribed by a state-licensed prescriber with active DEA registration). There are no inactive, pending, or non-controlled-only licenses. U.S. territories (Puerto Rico, Guam, U.S. Virgin Islands, American Samoa, Northern Mariana Islands) are not included.

Accreditations

  • VPP inspected
  • NABP Healthcare Merchant accredited
  • LegitScript certified
## Jurisdiction coverage 51 active pharmacy licenses. Controlled substances: yes, in every jurisdiction.
| Jurisdiction | Code | Status | Controlled | | - | - | - | - | | Alabama | AL | Active | Yes | | Alaska | AK | Active | Yes | | Arizona | AZ | Active | Yes | | Arkansas | AR | Active | Yes | | California | CA | Active | Yes | | Colorado | CO | Active | Yes | | Connecticut | CT | Active | Yes | | Delaware | DE | Active | Yes | | District of Columbia | DC | Active | Yes | | Florida | FL | Active | Yes | | Georgia | GA | Active | Yes | | Hawaii | HI | Active | Yes | | Idaho | ID | Active | Yes | | Illinois | IL | Active | Yes | | Indiana | IN | Active | Yes | | Iowa | IA | Active | Yes | | Kansas | KS | Active | Yes | | Kentucky | KY | Active | Yes | | Louisiana | LA | Active | Yes | | Maine | ME | Active | Yes | | Maryland | MD | Active | Yes | | Massachusetts | MA | Active | Yes | | Michigan | MI | Active | Yes | | Minnesota | MN | Active | Yes | | Mississippi | MS | Active | Yes | | Missouri | MO | Active | Yes | | Montana | MT | Active | Yes | | Nebraska | NE | Active | Yes | | Nevada | NV | Active | Yes | | New Hampshire | NH | Active | Yes | | New Jersey | NJ | Active | Yes | | New Mexico | NM | Active | Yes | | New York | NY | Active | Yes | | North Carolina | NC | Active | Yes | | North Dakota | ND | Active | Yes | | Ohio | OH | Active | Yes | | Oklahoma | OK | Active | Yes | | Oregon | OR | Active | Yes | | Pennsylvania | PA | Active | Yes | | Rhode Island | RI | Active | Yes | | South Carolina | SC | Active | Yes | | South Dakota | SD | Active | Yes | | Tennessee | TN | Active | Yes | | Texas | TX | Active | Yes | | Utah | UT | Active | Yes | | Vermont | VT | Active | Yes | | Virginia | VA | Active | Yes | | Washington | WA | Active | Yes | | West Virginia | WV | Active | Yes | | Wisconsin | WI | Active | Yes | | Wyoming | WY | Active | Yes |
# Building by Blend Source: https://docs.byblend.com/overview Welcome to the Blend API documentation Task-focused answers to specific questions — sending prescriptions, creating and editing orders, resolving stuck orders, and managing prescribers, products, and reporting. Start here if you know what you need to do. # General Concepts ### Products Products are your business's individual "SKUs," whether prescription or non-prescription. These entities contain descriptive information, pricing, your own product code/identifier, and other (generally) patient-facing information. Blend will manage underlying inventory for your products. ### Prescribers The healthcare professionals who will prescribe your prescription products, and who will be sending Electronic Prescriptions. Prescriber regulatory information (NPI/SPI), licensing credentials, supervisory relationships (if applicable), address/contact and biographical information are required to be kept up-to-date within Blend. ### Electronic Prescriptions Electronic Prescriptions, sent via either the Surescripts network or directly via API, are required to fill an order containing prescription products. Each prescription product in an order needs an active/non-expired prescription with fills remaining. ### Patients The individuals who will receive products directly fulfilled by Blend. Patient profiles in Blend must be kept up-to-date, including name, address, contact information, and (critically) any risk factors: allergies, drug interactions, pre-existing conditions, pregnancy state, etc. ### Orders Orders are the unification of the above that result in (in most cases) a filled prescription, packaged product(s) in your custom packaging, and a shipping box sent straight to your patient. # Blend End-to-End Each of the above is required to be created within Blend for an order to be filled end-to-end. *For the most part*, the above entities can be created in any order. Blend systems will match accordingly when all data is available. The happiest path, however, is the following: ```mermaid theme={null} flowchart TB subgraph live[Order Flow] direction TB subgraph 3[New Patients] direction TB patient(Create Patient) -->prescription(Send Prescription) -->order(Create Order) end subgraph 4[Existing Patients] direction TB prescription2(Send Prescription) -->order2(Create Order) end subgraph 5[Refill] direction TB order3(Create Order) end end subgraph before[Onboarding] direction LR top1(Create Products) bottom1(Create Prescribers) end style live fill:#fff,stroke:#5d6b68 style before fill:#FEE0A8 style 3 fill:#f9fbfb,stroke:#5d6b68 style 4 fill:#f2f7f7,stroke:#5d6b68 style 5 fill:#dfecec,stroke:#5d6b68 ``` *Please also note the single Composite Creation option, below, for specific use cases of specific customer types.* ### During Onboarding: Create Products and Prescribers During your Blend onboarding, we will work with you to create initial products and match them accordingly with your own EMR or similar systems. We will likewise work with you to bulk import existing prescribers and their licensing and other information. Depending on your approach to existing patients and prospective refill prescriptions, we can also import / create patient records in advance. ### For New Patient Orders: Create (a New) Patient, Prescription, and Order At the time of an order, your systems should be prepared to create the following entities within Blend. * A **patient**, using the `/patients` endpoint. * Alternatively, this can be created within an Order in a single request * Not applicable for refills, as patient data already exists * An **electronic prescription** (assuming the patient requires a prescribed product) * This can be sent via Surescripts, or directly via API (`/prescriptions/electronic-prescription`) depending on your integration * An **order**, using the `/orders` endpoint, containing the product(s) to be fulfilled by Blend *While a patient must be created before sending an order, a prescription can be sent at any time (even before patient creation). Blend will match accordingly regardless of which is created first.* ### For Existing Patient Orders: Create a Prescription and Order For existing patients (non-refill) orders, your system needs to only send: * An **electronic prescription**, either via Surescripts or directly via API * An **order** containing the product(s) to be fulfilled ### For Refill Orders: Create an Order * Refills of existing prescriptions can be fulfilled simply be sending a new order # Composite Creation For customers who wish to streamline their API usage, Blend offers a "composite" endpoint, a convenience function wherein you can create an Electronic Prescription, Order, and even a new Patient and Prescriber, in a single request. This Composite endpoint expects up to four objects in a request -- `electronic_prescription`, `order`, `patient`, `prescriber` -- with each adhering to its individual endpoint required fields. Patients and prescribers can be passed by reference. # How Blend Matches Patients, Orders, Prescribers, Prescriptions and Products There are a few key data fields Blend uses to match entities. ### Prescription to Patient * If directly provided via API, Blend will look for a patient's `id` (Blend ID) or `external_id` (your own identifier that can be stored in Blend patient profiles). * For Surescripts prescriptions, Blend will match on patient name (or preferred name) and date of birth; or patient contact information and date of birth. ### Prescription to Prescriber * Prescribers will be matched based on NPI, DEA number, or SPI, with a fallback to name and date of birth ### Prescription to Product * If directly provided via API, Blend will look for a `product` ID (Blend ID) or `product_code` in your request * For Surescripts prescriptions, Blend will parse the ``, the `` or `` fields for matches to your products' `sku`, `product_code`, `ID`, or even its `name`. ### Prescription to Order * Because a `patient` must be sent with an order, Blend will leverage the above mapping to tie orders to prescriptions via patient-match. # Order Merging Blend will attempt to consolidate open orders for the same patient. If a new order is created (either via API or in the Blend Dashboard) while a patient has an existing "open" order, the new order will be automatically merged into the existing order. ### Open (Mergeable) Orders An open or mergeable order is one in `received` or `paused` status, or an `exception` (stuck) order created within the last 24 hours. That lets same-day prescriptions still ship together if a Too Early to Fill hold is released. Older exception orders are not merged into, so a long-standing hold on one medication does not delay unrelated new prescriptions. Once an order has entered the physical picking phase (`picked` or later), it can no longer be merged-into, and a new order will be created for that patient. ### Shipping Updates Upon Merge If a new order is merged into an existing order, any shipping address or preference updates **will** be inherited by the original order: * If a new shipping address is provided, the merged order will be sent to the new shipping address. * If a new/different shipping preference is provided (e.g., carrier or service level), the merged order will use the new preference. ### Merge response If your attempt to create a new order has been merged with an existing open order for that patient, you will receive the original (existing) order information in response to your Create Order request. In addition, this response will include `"merged_into_existing": true` to confirm a merge has occurred. ### Overriding order merge You may send the `force_new=true` querystring argument when creating a new order (in either the Create Order or Composite endpoints) to prevent order merging. For instance, if a patient has requested a separate order be sent to a different location, you will want to maintain separate orders. # Privacy Policy Source: https://docs.byblend.com/privacy Blend Innovations, Inc. – Privacy Policy Effective Date: January 26, 2026 ## **Introduction** Blend Innovations, Inc. and its subsidiaries and affiliates (“Blend,” “we,” “us,” or “our”) operate a technology-enabled compounding pharmacy platform, including our website, platform, and APIs (the “Services”). This Notice of Privacy Practices and Privacy Policy (“Notice”) explains how we collect, use, share, and protect your personal and health information. It also describes the rights you have regarding your health information and how you can exercise them. This Notice applies to all of our Services and is incorporated into our [Terms of Service](https://docs.byblend.com/terms). ## **Information We Collect** We collect information that is necessary to provide our pharmacy services and operate our platform, including: * **Information you provide**: such as your name, contact details, shipping address, and payment information. * **Health information**: including prescriptions, prescriber details, medical history, allergies, and other information required to dispense medications. * **Information from others**: including prescribers, clinics, or telehealth platforms who send us your prescription or related information. * **Automatically collected information**: such as device/browser type, IP address, and site usage analytics. * **Marketing prospect data**: collected separately through cookies, analytics, and similar tools. This data is **not combined with your health information**. ## **How We Use Information** We use your information for purposes allowed by law, including: * Filling, dispensing, and shipping your prescriptions. * Communicating with you and your prescriber about your medications. * Meeting our legal and regulatory obligations as a pharmacy. * Conducting internal analytics and improving our services using **only de-identified and aggregated data**. * Managing business operations such as audits, quality assurance, and compliance. We do **not** use your health information for marketing purposes, and we do **not** sell your information. ## **How We Share Information** We may share your information in the following situations: * **With your prescribers or clinics** as needed to fulfill your prescriptions. * **With service providers** that help us operate (such as shipping companies, technology providers, and communication tools). * **As required by law** for audits, inspections, reporting, or in response to valid legal processes. * **For safety or public health purposes**, if disclosure is needed to prevent a serious threat to health or safety. * **In business transactions**, such as a merger, acquisition, or transfer of assets. ## **Your Rights** You have important rights with respect to your health information, including the right to: * **Access**: You can request a copy of your health information. * **Amend**: You may request corrections if your information is inaccurate or incomplete. * **Accounting of disclosures**: You may request a list of certain disclosures we have made of your information. * **Request restrictions**: You can ask us to limit how your information is used or shared, though we may not always be able to agree when restricted by law. * **Confidential communications**: You may request that we communicate with you in a specific way (for example, by using a different address). * **Paper copy**: You may request a paper copy of this Notice at any time. To exercise these rights, please first contact your prescriber. If your prescriber cannot resolve your request, you may contact us directly at **[privacy@byblend.com](mailto:privacy@byblend.com)**. ## **Cookies and Tracking** We use cookies, pixels, and analytics tools on our website to understand how visitors interact with our Services. This information is used for business prospecting and operational purposes and is never linked with patient health information. Marketing prospect data is retained for **5 years** and then securely deleted. ## **Text Messaging and Business Communications** We may collect and use phone numbers provided by our customers and business partners (including clinics and their authorized personnel) for the purpose of operational, administrative, and customer support communications. These communications may occur via text message (SMS), phone call, or similar messaging technologies and may be facilitated through third-party service providers. Text messaging is used solely for business-related purposes, including but not limited to: * Responding to support inquiries * Resolving operational issues * Providing account-related information * Communicating about services, features, or system status We do not use text messaging for unsolicited marketing or promotional messages without appropriate consent. By providing a phone number to us, you represent that you are authorized to do so and consent to receiving business-related communications from us at that number. Message frequency will vary based on the nature of the interaction. Standard message and data rates may apply. You may opt out of text communications at any time by replying "STOP" or by contacting us directly. Opting out of text messages may limit our ability to provide timely support or operational updates. We may share phone numbers and related communication data with trusted service providers that assist us in delivering these communications, subject to contractual confidentiality and data-protection obligations. We do not sell phone numbers or use them for third-party advertising. ## **Data Retention** * Prescription and medical records are retained for **10 years** as required by pharmacy law. * Health information cannot be deleted early, even if requested, because of legal retention requirements. * Prospect marketing data is retained for **5 years**. * De-identified data may be retained for analytics purposes. ## **California Privacy Rights (CCPA/CPRA)** If you are a California resident, you have additional rights under California law: * **Right to know**: You can request details about the personal information we collect, use, and disclose. * **Right to delete**: You can request deletion of personal information, subject to pharmacy record retention laws. * **Right to correct**: You can request that we correct inaccurate personal information. * **Right to opt-out of sale/sharing**: You can request that we do not sell or share your personal information. (Blend does not sell patient health information.) * **Right to non-discrimination**: You will not be treated differently for exercising your privacy rights. To make a request under CCPA/CPRA, email us at **[privacy@byblend.com](mailto:privacy@byblend.com)**. We will take steps to verify your identity before fulfilling your request. ## **Children’s Privacy** Blend does not knowingly collect personal information directly from children under 13 years of age through its websites, apps, or digital Services. Our digital Services are directed to adults, including parents and legal guardians, and are not designed for use by children. If you are under 13, you may not register for or directly use Blend’s digital Services. At the same time, as a licensed pharmacy, Blend does dispense medications to patients under the age of 13. In those cases, all prescription and account activity occurs through the child’s parent or legal guardian, who is responsible for managing the child’s prescription orders. Any personal or health information we maintain for pediatric patients is collected and used solely to provide pharmacy services in coordination with the child’s prescriber and parent or guardian, and is protected under our Privacy Policy. If Blend learns that we have inadvertently collected information directly from a child under 13 through our digital Services, we will promptly delete such information. Parents or guardians who believe we may have information collected directly from a child through the website should contact us at [privacy@byblend.com](mailto:privacy@byblend.com). ## **Security** We implement reasonable administrative, technical, and physical safeguards to protect the confidentiality, integrity, and availability of personal and patient-related information. These include access controls, encryption in transit and at rest, secure storage practices, auditing of system access, and regular monitoring for unauthorized activity. However, no system or method of data storage is completely secure. While we take steps to reduce risk, we cannot guarantee that information will never be accessed, disclosed, altered, or lost in a manner inconsistent with this Privacy Policy. Where the Services allow individuals to submit content directly (e.g., forms or messages), we recommend excluding any sensitive information not required for appropriate treatment. Personal and health-related data should be submitted only through Blend-provided secure forms, not via external messaging applications. ## **Changes to this Notice** We may update this Notice from time to time. When we do, we will post the updated version on our website with a new **Effective Date**. If we make material changes to how we use or share your information, we will notify you by email. ## **Contact Us** If you have any questions about this Notice or your privacy rights, you can contact us at: * **Chief Privacy Officer** * Blend Innovations, Inc. * 6171 Huntley Rd STE J * Columbus, OH 43229 * Email: **[privacy@byblend.com](mailto:privacy@byblend.com)** ## Notice of Privacy Practices ### Your Rights When it comes to your health information, you have certain rights. This section explains your rights and some of our responsibilities to help you. **Get an electronic or paper copy of your medical record** * You can ask to see or get an electronic or paper copy of your medical record and other health information we have about you. Ask us how to do this. * We will provide a copy or a summary of your health information, usually within 30 days of your request. We may charge a reasonable, cost-based fee. **Ask us to correct your medical record** * You can ask us to correct health information about you that you think is incorrect or incomplete. Ask us how to do this. * We may say “no” to your request, but we’ll tell you why in writing within 60 days. **Request confidential communications** * You can ask us to contact you in a specific way (for example, home or office phone) or to send mail to a different address. * We will say “yes” to all reasonable requests. **Ask us to limit what we use or share** * You can ask us not to use or share certain health information for treatment, payment, or our operations. * We are not required to agree to your request, and we may say “no” if it would affect your care. * If you pay for a service or health care item out-of-pocket in full, you can ask us not to share that information for the purpose of payment or our operations with your health insurer. * We will say “yes” unless a law requires us to share that information. **Get a list of those with whom we’ve shared information** * You can ask for a list (accounting) of the times we’ve shared your health information for six years prior to the date you ask, who we shared it with, and why. * We will include all the disclosures except for those about treatment, payment, and health care operations, and certain other disclosures (such as any you asked us to make). We’ll provide one accounting a year for free but will charge a reasonable, cost-based fee if you ask for another one within 12 months. **Get a copy of this privacy notice** * You can ask for a paper copy of this notice at any time, even if you have agreed to receive the notice electronically. We will provide you with a paper copy promptly. **Choose someone to act for you** * If you have given someone medical power of attorney or if someone is your legal guardian, that person can exercise your rights and make choices about your health information. * We will make sure the person has this authority and can act for you before we take any action. **File a complaint if you feel your rights are violated** * You can complain if you feel we have violated your rights by contacting us using the information on page 1. * You can file a complaint with the U.S. Department of Health and Human Services Office for Civil Rights by sending a letter to 200 Independence Avenue, S.W., Washington, D.C. 20201, calling 1-877-696-6775, or visiting [www.hhs.gov/ocr/privacy/hipaa/complaints/](http://www.hhs.gov/ocr/privacy/hipaa/complaints/). * We will not retaliate against you for filing a complaint. ### Your Choices For certain health information, you can tell us your choices about what we share. If you have a clear preference for how we share your information in the situations described below, talk to us. Tell us what you want us to do, and we will follow your instructions. **In these cases, you have both the right and choice to tell us to:** * Share information with your family, close friends, or others involved in your care * Share information in a disaster relief situation * Include your information in a hospital directory * Contact you for fundraising efforts *If you are not able to tell us your preference, for example if you are unconscious, we may go ahead and share your information if we believe it is in your best interest. We may also share your information when needed to lessen a serious and imminent threat to health or safety.* **In these cases we never share your information unless you give us written permission:** * Marketing purposes * Sale of your information * Most sharing of psychotherapy notes **In the case of fundraising:** * We may contact you for fundraising efforts, but you can tell us not to contact you again. ### Our Uses and Disclosures How do we typically use or share your health information? We typically use or share your health information in the following ways. **Treat you** * We can use your health information and share it with other professionals who are treating you. * Example: A doctor treating you for an injury asks another doctor about your overall health condition. **Run our organization** * We can use and share your health information to run our practice, improve your care, and contact you when necessary. * Example: We use health information about you to manage your treatment and services. **Bill for your services** * We can use and share your health information to bill and get payment from health plans or other entities. * Example: We give information about you to your health insurance plan so it will pay for your services. **How else can we use or share your health information?** We are allowed or required to share your information in other ways – usually in ways that contribute to the public good, such as public health and research. We have to meet many conditions in the law before we can share your information for these purposes. For more information see: [www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/index.html](http://www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/index.html). **Help with public health and safety issues**\ We can share health information about you for certain situations such as: * Preventing disease * Helping with product recalls * Reporting adverse reactions to medications * Reporting suspected abuse, neglect, or domestic violence * Preventing or reducing a serious threat to anyone’s health or safety **Do research** * We can use or share your information for health research. **Comply with the law** * We will share information about you if state or federal laws require it, including with the Department of Health and Human Services if it wants to see that we’re complying with federal privacy law. **Respond to organ and tissue donation requests** * We can share health information about you with organ procurement organizations. **Work with a medical examiner or funeral director** * We can share health information with a coroner, medical examiner, or funeral director when an individual dies. **Address workers’ compensation, law enforcement, and other government requests**\ We can use or share health information about you: * For workers’ compensation claims * For law enforcement purposes or with a law enforcement official * With health oversight agencies for activities authorized by law * For special government functions such as military, national security, and presidential protective services **Respond to lawsuits and legal actions** * We can share health information about you in response to a court or administrative order, or in response to a subpoena. ### Our Responsibilities * We are required by law to maintain the privacy and security of your protected health information. * We will let you know promptly if a breach occurs that may have compromised the privacy or security of your information. * We must follow the duties and privacy practices described in this notice and give you a copy of it. * We will not use or share your information other than as described here unless you tell us we can in writing. If you tell us we can, you may change your mind at any time. Let us know in writing if you change your mind. For more information see: [www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/noticepp.html](http://www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/noticepp.html). **Changes to the Terms of This Notice**\ We can change the terms of this notice, and the changes will apply to all information we have about you. The new notice will be available upon request, in our office, and on our web site. This Notice of Privacy Practices applies to the following organizations: By Blend LLC # Security Source: https://docs.byblend.com/security Blend's approach to data and system security Our platform is designed with security, compliance, and accountability as core principles. We adhere to security practices aligned with **HIPAA** and **SOC 2** frameworks to safeguard sensitive information. ## Data * **Encryption in Transit**: All network traffic is encrypted via TLS 1.2+ with strong cipher suites. * **Encryption at Rest**: All persistent data is encrypted with AES-256. Databases and snapshots are encrypted at rest. Object storage uses server-side encryption (SSE-S3, AES-256) by default. * **Auditing**: All access to any customer, inventory, or protected health information (PHI) via API or dashboard is logged. All attempted, failed, and successful logins, as well as data edits or modifications, are recorded and auditable, and regularly audited. ## Infrastructure * **Private Networking**: Services communicate over an internal private network using secure internal DNS. * **System Monitoring**: Continuous collection of logs and performance metrics (CPU, memory) with alerting for anomalous behavior. * **Observability Dashboards**: Custom dashboards provide real-time visibility into system health, performance, and deployment activity. * **Backups**: Automated backups with tested restoration procedures are performed daily, weekly, and monthly. * **Patch Management**: Operating systems and dependencies are regularly updated to remediate vulnerabilities. ## Application & Operational * **Secure Development Practices**: Code reviews, dependency vulnerability scanning, and secrets management. * **Identity Verification**: Positive ID procedures are required and enforced for all in-pharmacy operations for prescription review or medication dispensation. * **Audit Trails**: Comprehensive audit trails for all system access, data changes, and pharmacy operations. ## Network Controls * **Encrypted Transport**: All external connections are served over HTTPS with modern TLS protocols (1.2+). Certificates are automatically issued and renewed. * **Connection Limits & Rate Controls**: Baseline rate limiting and connection caps are enforced at the network edge to prevent abuse and ensure service stability. * **Resilience Against Attacks**: Network layer is protected against denial-of-service attempts, with safeguards in place to maintain availability. ## Compliance & Certifications * **EPCS / DEA 21 CFR Part 1311**: Certified and audited (every two years) for Electronic Prescriptions for Controlled Substances (EPCS) under DEA 1311 standards. *Most recent audit September 2025.* * **Surescripts Certification**: Certified for interoperability with the Surescripts network, which enforces **mutual TLS (mTLS)** and strict identity controls for all electronic prescription interchange. * **HIPAA Alignment**: We implement HIPAA-aligned controls for auditing, access restrictions, and confidentiality. * **SOC 2 Alignment**: We follow SOC 2 security principles, including: * Access controls (least privilege, audit logs). * Encryption in transit and at rest. * Change management and code review. All changes pass through version control, automated test suites, and a staging environment before production deployment. * Incident response procedures. We continuously and automatically monitor systems and have escalation processes in place to respond rapidly to anomalies or security events. Any incidents are documented, reviewed, and addressed as part of a structured post-incident review process. * Vendor Risk & Redundancy. Critical vendors are evaluated for compliance with recognized security and industry standards. Vendor dependencies are periodically reviewed. Key infrastructure is deliberately provisioned across multiple vendors to improve resilience and reduce the risk of single points of failure. # Terms of Service Source: https://docs.byblend.com/terms Blend Innovations, Inc. – Terms of Service **Effective Date: August 29, 2025** ## **1. Agreement to Terms** These Terms of Service (“Terms”) govern your access to and use of our websites (including byblend.com), technology platform, software, APIs, and pharmacy fulfillment services (collectively, the “Services”) provided by Blend Innovations, Inc. and its subsidiaries and affiliates (together, “Blend,” “we,” “us,” or “our”).By accessing or using the Services, you agree to be bound by these Terms. Your acceptance is implied by your continued use of the Services. If you are a clinic, platform, or other business partner that has entered into a separate written agreement with Blend, the terms of that written agreement will control in the event of any conflict with these Terms. These Terms apply to all other users, including individual patients who access limited features of the Services. ## **2. Services Provided** Blend provides technology-enabled compounding pharmacy services, including prescription fulfillment, logistics support, and digital access tools. Blend does not provide medical advice or clinical care other than pharmacy services. All medical advice, diagnoses, and prescribing decisions are the sole responsibility of licensed healthcare providers. The Services include both the provision of pharmacy fulfillment services and access to digital technology tools that support those services. ## **3. Users Covered** These Terms apply both to business accounts, including clinics and telehealth platforms, and to individual patients who may use certain limited features of the Services. ## **4. Section for Patients** If you are an individual patient, please note the following: Blend is not your healthcare provider and does not provide medical advice. Any diagnosis, treatment plan, or prescribing decision is made solely by your licensed healthcare provider. Your access to the Services is limited to viewing, managing, and receiving prescription orders. Your personal information is protected in accordance with Blend’s [Privacy Policy](https://docs.google.com/document/d/1GfTeV1FU7DYcxTGP_9BWsPDXi5vCu-L06rTXPlC8Sq4/edit?tab=t.0). If you have concerns about your prescription, you must contact your prescriber directly. Blend’s liability to you as a patient is limited to one hundred dollars (\$100), except where prohibited by law. ## **5. Accounts and Responsibilities** Both individuals and organizations may create accounts to use the Services. You agree to provide accurate and complete information when creating an account and to safeguard your login credentials. Unless otherwise provided in a separate written contract, Blend reserves the right to suspend or terminate accounts at any time, including immediately where we suspect fraud, diversion, regulatory risk, or other noncompliance. Suspension or termination does not relieve you of any payment obligations incurred prior to termination. ## **6. API Terms** Blend may provide access to application programming interfaces (“APIs”) for integration purposes. Your use of any API is subject to these Terms and any API documentation provided by Blend. You may use the APIs only for lawful, authorized purposes and in accordance with applicable documentation. You may not access internal-only (undocumented) APIs, reverse engineer APIs, resell or sublicense your access to APIs, or use APIs to build competing services. The use of any third-party tool to extract data (“scrape”) from Blend systems, or otherwise replicate or expand upon existing API functionality, is unauthorized. Blend may monitor API usage, impose limits, and revoke access at any time. Blend also reserves the right to introduce fees for API access in the future. ## **7. Payments and Fees** Payment terms depend on how you access the Services. If you are invoiced, the terms set out in your invoice will govern, including due dates and any late payment provisions. If you pay by credit card or other electronic method, you will be presented with applicable payment and privacy terms at the time of payment. If you are a patient who does not directly pay Blend, no billing will occur unless explicitly stated. ## **8. Privacy** Your use of the Services is also governed by Blend’s Privacy Policy, available at [byblend.com/privacy](https://docs.byblend.com/privacy). These documents are incorporated by reference into these Terms. ## **9. Intellectual Property** All rights, title, and interest in and to the Services, including the software, trademarks, content, and documentation, belong exclusively to Blend and its licensors. You are granted a limited, revocable, non-exclusive, non-transferable license to use the Services for their intended purposes. You may not copy, modify, reverse engineer, or distribute the Services or related content. No right to co-branding or use of Blend’s trademarks is granted without our express written consent. ## **10. Prohibited Uses** You agree not to use the Services in violation of any laws or regulations, including those governing pharmacy practice and controlled substances. You may not submit fraudulent or forged prescriptions, attempt to gain unauthorized access to systems or data, or interfere with the operation of the Services through malware, scraping, or other disruptive activities. ## **11. Third-Party Providers** Blend is not responsible for the clinical decisions of independent prescribers, the performance or timeliness of delivery carriers, or the operation of third-party technology vendors or platforms that may integrate with Blend. ## **12. Dispute Resolution** These Terms are governed by the laws of the State of Ohio, without regard to conflict-of-law principles. Except where prohibited by law, any dispute arising under these Terms shall be resolved by binding arbitration conducted in Ohio on an individual basis, and not as part of a class or collective action. If you are a business partner and have a separate written agreement with Blend, the dispute resolution provisions in that agreement will govern in the event of conflict. ## **13. Modifications** Blend may update these Terms from time to time by posting changes on our website. Changes are effective immediately upon posting. For material changes affecting access by business partners, Blend will provide reasonable notice, which may be delivered by email or through the Services portal. Your continued use of the Services after changes take effect constitutes acceptance of the updated Terms. ## **14. Disclaimers and Limitations of Liability** The Services are provided “as is” and without warranties of any kind, whether express or implied. Blend disclaims liability for indirect, incidental, or consequential damages. For business accounts, Blend’s aggregate liability for all claims is limited to the total amounts paid to Blend in the twelve (12) months preceding the claim. For individual patients, Blend’s liability is limited to one hundred dollars (\$100). These limitations apply to the maximum extent permitted by law. ## **15. General Provisions** Blend may assign these Terms without restriction. You may not assign or transfer these Terms without Blend’s prior written consent. Blend will not be liable for delays or failures in performance caused by circumstances beyond our reasonable control, including acts of God, natural disasters, strikes, or governmental actions. Notices to Blend must be sent electronically to [admin@byblend.com](mailto:admin@byblend.com). These Terms, together with the Privacy Policy and any other referenced policies, constitute the entire agreement between you and Blend regarding your use of the Services. If any provision of these Terms is held unenforceable, the remaining provisions shall remain in full force and effect. **Contact Information** * Blend Innovations, Inc. * Email: [admin@byblend.com](mailto:admin@byblend.com) * Website: [byblend.com](https://www.byblend.com)