curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=ed&questionnaire=sildenafil" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/visits" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "external_visit_id": "consult-1001",
    "external_patient_id": "acme-patient-90210",
    "questionnaire_type": "glp-1",
    "questionnaire": {
      "code": "weight",
      "type": "glp-1",
      "answers": [
        { "id": "weight_product", "answer": "semaglutide" },
        { "id": "height", "answer": { "feet": 5, "inches": 10 } },
        { "id": "pounds", "answer": "220" }
      ]
    }
  }'

curl -X PUT "https://a-nirwan.bespoke-consults.designingit.co/v1/visits/consult-1001/questionnaire" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "questionnaire_type": "glp-1",
    "questionnaire": {
      "code": "weight",
      "type": "glp-1",
      "answers": [
        { "id": "weight_product", "answer": "semaglutide" },
        { "id": "height", "answer": { "feet": 5, "inches": 10 } },
        { "id": "pounds", "answer": "220" }
      ]
    }
  }'

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/visits/consult-1001/images" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "face_url": "https://cdn.partner.example/patients/pt-1/face.jpg",
    "photo_id_url": "https://cdn.partner.example/patients/pt-1/id-front.jpg"
  }'

{
  "lab_files": [
    {
      "url": "https://files.yourapp.com/labs/cmp-2026-10.pdf",
      "filename": "cmp-2026-10.pdf",
      "content_type": "application/pdf"
    }
  ]
}

Bespoke Prescription API — Developer Guide

Version 1.3

This guide is everything you need to integrate with the Bespoke Prescription API: authentication, endpoints, request and response payloads, status lifecycle, errors, and recommended patterns.

External references

Partners should send stable external ids so Bespoke updates existing objects instead of creating disconnected snapshots. Typed aliases are accepted and returned alongside the legacy external_ref / brand_code names:

Recommended minimum: external_patient_id, external_visit_id, external_product_id. Look up a prescription with GET /prescriptions/{external_prescription_id}.

What the API does

You submit clinical consults (visits). When a Bespoke provider approves a consult, Bespoke creates the prescriptions for fulfilment. You then:

1. Track those prescriptions with GET /prescriptions
2. Receive status as the order is accepted, shipped, and delivered

You can also manage patients independently via /v1/patients (create/upsert, retrieve, update). Reuse the same external_ref on later consults so demographics are not duplicated.

One partner account can own many brands (sub-companies). Send brand_code on patients and prescriptions so Bespoke knows which brand every record belongs to. Omitted brand_code uses the partner's default brand. Hierarchy:

Partner → Brand → Patient → Visit → Prescription

You track progress by polling GET /prescriptions/{submission_id} and/or receiving outbound partner webhooks (configured per account).

Your system  →  POST /v1/patients              →  Bespoke patient record (optional first step)
Your system  →  POST /v1/visits                →  Bespoke consult (Open / stored `pending` + questionnaire)
Your system  ←  webhook consultation.created
Your system  →  PUT  /v1/visits/{id}           →  clinic / practitioner / metadata (no status change)
Prescriber   →  Completed or Declined           →  Bespoke consult decision
Your system  ←  webhook consultation.approved | declined
                 ↳ on approve: fills + doctor details + pharmacy-compatible e-script fields
Your system  ←  GET  /v1/prescriptions/{id}    ←  status updates (uuid or external_prescription_id)

Partner webhooks (callbacks)

Outbound webhooks are disabled by default. A Bespoke admin enables them on your account; you then configure the callback URL in Partner dashboard → Integration → Webhooks.

Full webhook contract (events, signatures, decline codes, pharmacy return):
/docs/webhooks

Booked video and audio calls send appointment.* events (including appointment.reminder an hour before each call) and consultation.call_requested: /docs/scheduling

Base URL

https://a-nirwan.bespoke-consults.designingit.co/v1

Replace the host with the URL your account manager provides for sandbox or production.

All requests must use HTTPS. Plain HTTP is rejected.

Authentication

Every request requires the credential headers, plus the website the call is for:

GET /v1/ping HTTP/1.1
Host: api.bespoke.example
X-Api-Key: bsk_live_7Qd3xR2mVn8pLc4KfW1sTbYz
X-Api-Secret: <your secret>
Accept: application/json

Credentials are issued in the Bespoke partner dashboard. The secret cannot be recovered later; if it is lost, rotate the credential and deploy the new pair.

Rotation issues a new pair and keeps the previous pair valid for 24 hours so you can cut over without downtime.

Never put credentials in a query string. Never call the API from a browser or mobile app — only from your backend. Send X-Source-Domain with the hostname of the website the call is for (clinic.example.com, or a full URL whose host is that name). Bespoke also accepts the host of Origin or Referer. The call is refused unless that hostname and the source IP are both on the allow-list an admin registered for your company. The source IP is your server's address. When the call reaches Bespoke through Cloudflare, that is the caller address Cloudflare reports, not a Cloudflare edge address. Allow-list your own server IP.

Sandbox keys use the bsk_test_ prefix. Live keys use bsk_live_.

Request and response conventions

Idempotency

Write endpoints such as POST /visits and POST /patients upsert by your external ids, so retrying the same payload updates the existing record instead of creating a duplicate. Prescriptions are not created via the API.

Rate limits

120 requests per minute per account (default). Over the limit:

• HTTP 429
• Code rate_limited
• Header Retry-After (seconds)

Back off and retry. Do not busy-loop.

Endpoints

GET /ping

Smoke-test credentials (useful in deploy pipelines).

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/ping" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

200 OK

{
  "status": "ok",
  "account": "Acme Health",
  "environment": "live",
  "server_time": "2026-08-12T11:14:03+00:00"
}

GET /question-categories

Lists treatment categories and the questionnaires inside each one. The catalog is the same for every partner.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/question-categories" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

Each category has slug, name, prescription_interval_days, and questionnaires (code, title, question_count).

prescription_interval_days is the default number of days between each prescription for that category. It is null when Bespoke has not set a gap. A partner can set a different gap with that category's rate; that partner gap is what the consult uses. Send the category slug as questionnaire_type on the visit. The GLP-1 category slug is glp-1. glp1 is also accepted. MICC/B-12 is micc-b12. Glutathione is glutathione. Peptides is peptides. Women's HRT is hrt. Men's TRT is trt (questionnaire code mens-trt). Lab review is lab-review (see Lab review consults). An unknown slug returns 422 validation_failed. The error includes the questionnaires docs URL.

GET /questions

Returns the questions for one category. category is required. When a category has more than one questionnaire (ED has sildenafil and tadalafil), pass questionnaire to return only that form.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=glp-1" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=micc-b12" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=glutathione" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

MICC/B-12 and glutathione collect height in feet and inches and weight in pounds, the same shape as GLP-1. The weight question sets config.show_bmi so you can display BMI. Neither form rejects a low BMI. MICC/B-12 always requires highest_weight and target_weight. Glutathione follow-ups, optional questions (config.optional), and the acknowledgment that every statement must be selected are documented at /docs/questionnaires.

Unknown category or questionnaire returns 404. A missing category returns 422 validation_failed.

Answer type values:

When an option's reveals_input is set (for example choosing “Other” or “Yes”), show that extra field — usually a required text box labeled “Please specify”. A question with visible_when is shown only after an earlier answer matches (question_key, operator, value).

Send the collected answers on the visit as questionnaire.answers, using each question key as id. A submitted questionnaire must include every question that applies. Hidden follow-ups are not required. A partial answer list returns 422 validation_failed and is not stored. Conditional rules, the GLP-1 follow-ups, and the error shape are documented at /docs/questionnaires.

GET /medications

List medications the pharmacy network supports (and, when you have linked partner catalog products, only those linked items).

Query params: q (search name / strength / external id), brand_code / brand_id (limit to a brand's linked catalog).

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/medications?q=sema" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

200 OK

{
  "data": [
    {
      "medication_id": "3f2a1c8e-9b4d-4e6a-8f1c-2d7e9a0b5c4d",
      "external_product_id": "prx-sema-025",
      "name": "Semaglutide",
      "strength": "0.25mg",
      "ndc": null,
      "default_directions": "Inject 0.25 mg subcutaneously once weekly"
    }
  ]
}

Use external_product_id on consults when identifying a catalog product.

GET /products

Identical to GET /medications (path alias for partners that call the catalog “products”).

POST /patients

Create or update a standalone patient for your account. Identity is your external_ref (unique per account). Sending the same external_ref again updates demographics instead of creating a duplicate.

Returns 201 Created on first insert, 200 OK on update.

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/patients" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
  "external_ref": "acme-patient-90210",
  "first_name": "Dana",
  "last_name": "Whitfield",
  "date_of_birth": "1986-04-11",
  "gender": "female",
  "email": "dana@example.com",
  "phone": "3055551234",
  "address": {
    "line1": "123 Main Street",
    "line2": "Apt 4",
    "city": "Miami",
    "state": "FL",
    "postal_code": "33101"
  }
}'

201 / 200 response

{
  "patient_id": "3f2a1c8e-9b4d-4e6a-8f1c-2d7e9a0b5c4d",
  "external_ref": "acme-patient-90210",
  "brand_id": "7c1e9a2b-4d5f-4a8e-9c3b-1f0e2d4a6b8c",
  "brand_code": "brand-a",
  "first_name": "Dana",
  "last_name": "Whitfield",
  "date_of_birth": "1986-04-11",
  "gender": "f",
  "email": "dana@example.com",
  "phone": "305-555-1234",
  "address": {
    "line1": "123 Main Street",
    "line2": "Apt 4",
    "city": "Miami",
    "state": "FL",
    "postal_code": "33101"
  },
  "created_at": "2026-08-12T11:14:03+00:00",
  "updated_at": "2026-08-12T11:14:03+00:00"
}

Response patient_id is the Bespoke patient UUID. Use either patient_id or external_ref on later GET/PUT calls (add ?brand_code= when the same ref exists under multiple brands). Reuse the same external_ref + brand_code on later consults.

GET /patients/{external_ref_or_patient_id}

Retrieve one patient owned by your account. Path may be your external_ref or the Bespoke patient_id UUID.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/patients/acme-patient-90210" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

200 OK — same body as POST /patients. 404 not_found if unknown or owned by another account.

PUT /patients/{external_ref_or_patient_id}

Replace demographics for an existing patient. Path identifies the patient (external_ref or patient_id). Body uses the same fields as POST /patients except external_ref is optional (identity cannot be changed via the body).

200 OK on success. 404 if the patient does not exist for your account.

GET /patients

List patients for your account. Optional brand_code / brand_id to scope to one brand.

POST /visits

Open a clinical consult before sending a prescription. It starts Open (stored pending). Completing the consult is a separate explicit action — submitting an Rx never marks the visit Completed.

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/visits" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "external_ref": "consult-1001",
    "patient_ref": "acme-patient-90210"
  }'

Medical questionnaire (clinical — Bespoke only): send on POST /visits or PUT /visits/{id}/questionnaire. Providers review answers in the admin Visits screen before completing the consult and issuing a prescription.

Never sent to the pharmacy network. The pharmacy receives only the resulting prescription/order fields. Do not put questionnaire content in directions, metadata on prescriptions, or any pharmacy payload.

Example questionnaire body (shape only — send every visible question; see /docs/questionnaires):

{
  "code": "weight",
  "type": "glp-1",
  "answers": [
    { "id": "weight_product", "question": "Choose your GLP-1 medication", "answer": "semaglutide" },
    { "id": "height", "question": "Your height", "answer": { "feet": 5, "inches": 10 } },
    { "id": "pounds", "question": "Your current weight", "answer": "220" }
  ]
}

Test consultations (is_test)

Use a test consultation when your integration needs to exercise the full live path (create consult → provider approval → prescription relay to the pharmacy network) without treating the order as a real patient shipment.

Account requirement: a Bespoke admin must enable Test consultations on your partner account. If it is off, is_test: true returns 403 with code test_consults_disabled. Sandbox keys (bsk_test_) may still require is_test: true on every consult when your account is configured for live pharmacy smoke tests — your account manager will confirm.

Payload: set is_test to true on POST /visits. Use obviously fictional patient demographics and addresses reserved for testing. Do not use test consults for load testing.

{
  "external_ref": "consult-smoke-2026-11-05",
  "is_test": true,
  "patient_ref": "test-patient-smoke-001",
  "questionnaire_type": "glp-1",
  "requested_product": "semaglutide",
  "questionnaire": {
    "code": "weight",
    "type": "glp-1",
    "answers": []
  }
}

Send a complete questionnaire in production tests (same rules as a real consult). The example above omits answers for brevity.

While the consult is Open and still stored pending, you may set or clear is_test with PUT /visits/{id}. After a provider has opened the consult (in_progress) or closed it, is_test cannot be changed.

Responses: GET /visits, GET /visits/{id}, and prescription payloads include is_test: true when the consult was marked as a test. Test consults are labelled in the Bespoke prescriber UI. They are excluded from partner dashboard order and revenue metrics.

What Bespoke does at the pharmacy

Test consults follow the same approval and relay flow as production consults. When Bespoke successfully relays a test fill and the submission reaches accepted on the live pharmacy connection, Bespoke schedules a pharmacy cancellation after a short delay (1 minute by default, configurable on the Bespoke deployment). Your environment must run queue workers so the delayed job runs; with PHARMACY_LIVE=false (fixture driver), no live cancellation is scheduled.

Bespoke may also attach a test marker on the pharmacy order when the network supports it; that marker is best-effort only — do not rely on the pharmacy to skip fulfilment without Bespoke’s cancel step.

Multi-fill plans: only the first fill is relayed to the pharmacy (at consult approval). Later ladder steps stay queued with their intended start dates. The scheduled fill-release job (bespoke:release-due-fills) does not send later fills for is_test consults — they exist for API/UI smoke tests only, not live refills.

What your application should do

Cancellation is tied to the prescription, not to POST /visits. Do not call pause immediately after creating the consult — prescriptions do not exist until a provider approves the consult.

Recommended sequence:

1. POST /visits with is_test: true (and a complete questionnaire).
2. Wait for provider approval (GET /visits/{id} → stored completed, or webhook consultation.approved).
3. Poll GET /prescriptions or GET /prescriptions/{id} until status is accepted (relay is asynchronous; you may see queued → relaying first).
4. Backup (recommended): call POST /visits/{id}/prescriptions/pause or POST /prescriptions/{id}/pause with a reason such as "Integration smoke test". This is idempotent if Bespoke already scheduled or completed auto-cancel. Poll until status is paused or cancelled, or until you receive webhook prescription.cancelled when webhooks are enabled.

POST /v1/visits                    → 201, is_test: true, Open / pending
                                     … provider approves …
GET  /v1/prescriptions/{id}        → status=queued | relaying
GET  /v1/prescriptions/{id}        → status=accepted
                                     … after ~1m (configurable) Bespoke requests pharmacy cancel …
POST /v1/prescriptions/{id}/pause    → optional backup if still accepted
GET  /v1/prescriptions/{id}        → status=paused | cancelled

403 pharmacy_channel_required — pause/activate requires pharmacy routing on your account (same rules as production).

Errors

Withdraw an unused test consult while it is still Open and pending with POST /visits/{id}/cancel — that stops the consult before any prescription is created.

Lab test files (lab_files)

Send laboratory results with the consultation when the reviewing provider needs a panel, hormone result, or other lab PDF. This is separate from a questionnaire answer such as lab_results_url. lab_files is the consult-level list of files.

Account requirement: a Bespoke admin must enable Lab test files on your partner account. If it is off, a non-empty lab_files list returns 403 with code lab_files_disabled. Omitting lab_files is always allowed.

Where to send it: POST /visits and PUT /visits/{id}. There is no separate upload endpoint. You host the PDF and send an http or https URL. Bespoke does not accept multipart file uploads for lab files.

Only PDFs are accepted. An image, a missing type, or a non-PDF content_type returns 422 validation_failed and the consult is not updated with that list.

Lab files are clinical review data. They are never sent to the pharmacy network. They are not required on a consult, except a lab review, which needs at least one.

GET /visits and GET /visits/{id} return the stored list. Each item is filename, content_type, and url. The list is [] when none were sent.

{
  "external_ref": "consult-1001",
  "patient_ref": "acme-patient-90210",
  "questionnaire_type": "trt",
  "requested_product": "testosterone-men-s-trt",
  "lab_files": [
    {
      "url": "https://files.yourapp.com/labs/cmp-2026-10.pdf",
      "filename": "cmp-2026-10.pdf",
      "content_type": "application/pdf"
    }
  ]
}

To add or replace files after the consult exists:

curl -X PUT "https://a-nirwan.bespoke-consults.designingit.co/v1/visits/consult-1001" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "lab_files": [
      {
        "url": "https://files.yourapp.com/labs/hormones.pdf",
        "filename": "hormones.pdf",
        "content_type": "application/pdf"
      }
    ]
  }'

Errors

MICC + B-12 and Glutathione consults

These two products are weight-loss intakes. They do not use the GLP-1 form, and a low BMI is accepted. The product must already be on the partner catalog.

1. Load the questions before building the form.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=micc-b12" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=glutathione" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

2. Open the consult with POST /visits. Nest the patient, or send patient_id / patient_ref for a patient you already created. Set questionnaire_type, requested_product, and questionnaire.code from this table.

3. Put every question that applies in questionnaire.answers. Use each question key as id. Leave info questions out. Leave a follow-up out until its visible_when rule matches. A short list returns 422 validation_failed and the consult is not stored.

4. Do not call complete. The consult stays open until a Bespoke provider approves it. Then poll GET /visits/{id} and GET /prescriptions/{id}. You do not send a prescription count or the gap between fills.

state on the patient address is a 2-letter code. postal_code is 5 digits. date_of_birth is YYYY-MM-DD. Height is { "feet": 5, "inches": 10 }. Weight answers (pounds, and on MICC + B-12 also highest_weight and target_weight) are pounds. face_url and photo_id_url are optional HTTPS links.

MICC + B-12 always requires highest_weight and target_weight. current_medications may be the exact string I am not currently taking any medications. A Yes that asks for a note is { "value": "Yes", "input": "the note" }.

Glutathione asks for date of birth, sex at birth, and the state where the patient is located inside the questionnaire as well as on the patient. pregnancy_status is required only when sex_at_birth is not Male. hoped_results, lab_results_url, and additional_information may be omitted. acknowledgments must include every statement. A lab file, when sent, is an HTTPS URL.

Question rules and follow-ups are on /docs/questionnaires.

Peptide consults

Peptides is one intake for every peptide product. It is not the GLP-1 form, and there is no BMI cutoff. Load the questions, then open the consult with the product the patient selected.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=peptides" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

allergies may be the exact string I don't have any allergies. list_medications may be the exact string I don't take any medications. Choosing Other on primary_goal requires {"value": "Other", "input": "the goal"}. Leave info questions (intro_peptides, health_profile_intro, qualified_for_treatment) out of answers.

{
  "external_ref": "consult-peptides-1001",
  "patient_ref": "acme-patient-90210",
  "questionnaire_type": "peptides",
  "requested_product": "bpc-157",
  "questionnaire": {
    "code": "peptides",
    "type": "peptides",
    "answers": [
      { "id": "primary_goal", "answer": "Improve healing and recovery" },
      { "id": "height", "answer": { "feet": 5, "inches": 10 } },
      { "id": "pounds", "answer": "180" },
      { "id": "heart_conditions", "answer": ["No"] },
      { "id": "hormone_kidney_liver_conditions", "answer": ["No"] },
      { "id": "additional_conditions", "answer": ["No"] },
      { "id": "gastrointestinal_conditions", "answer": ["No"] },
      { "id": "cancer_diagnosis", "answer": "No" },
      { "id": "allergies", "answer": "I don't have any allergies" },
      { "id": "take_medications", "answer": ["None of the above"] },
      { "id": "list_medications", "answer": "I don't take any medications" },
      { "id": "conditions_already_reported", "answer": "No" }
    ]
  }
}

Women's HRT consults

Women's HRT is one intake. It is not the GLP-1 form, and there is no BMI cutoff. The category slug is hrt. The questionnaire code is hrt. women-hrt is a product-catalog slug, not a questionnaire category.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=hrt" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

Open the consult with POST /visits. Set questionnaire_type to hrt, questionnaire.code to hrt, and requested_product to the hormone the patient selected.

Send Estrogen Patches by that name. The patches share a family with other estradiol items, and the name keeps the consult on the patches.

symptoms is one or more option values. height is { "feet": 5, "inches": 6 }. pounds is weight in pounds. medications and concerns use Yes and No. The other yes/no questions use yes and no.

Show birth_control_method only when iud is yes. Show medical_conditions_list only when medical_conditions is not None. Show hormone_therapy_previous only when hormone_therapy is yes. Leave those answers out until the rule matches.

{
  "external_ref": "consult-hrt-1001",
  "patient_ref": "acme-patient-90210",
  "questionnaire_type": "hrt",
  "requested_product": "estrogen",
  "questionnaire": {
    "code": "hrt",
    "type": "hrt",
    "answers": [
      { "id": "symptoms", "answer": ["Hot Flashes", "Night Sweats"] },
      { "id": "lactating", "answer": "no" },
      { "id": "trying_pregnant", "answer": "no" },
      { "id": "birth_control", "answer": "yes" },
      { "id": "iud", "answer": "no" },
      { "id": "doctor_visit", "answer": "yes" },
      { "id": "medical_conditions", "answer": "None" },
      { "id": "hysterectomy", "answer": "no" },
      { "id": "oophorectomy", "answer": "no" },
      { "id": "allergies", "answer": "no" },
      { "id": "hormone_therapy", "answer": "no" },
      { "id": "medications", "answer": "No" },
      { "id": "concerns", "answer": "No" },
      { "id": "height", "answer": { "feet": 5, "inches": 6 } },
      { "id": "pounds", "answer": "150" }
    ]
  }
}

Men's TRT consults

Men's TRT is one intake. It is not the GLP-1 form. The category slug is trt. The questionnaire code is mens-trt. mens-trt is not the category slug.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=trt" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

Open the consult with POST /visits. Set questionnaire_type to trt, questionnaire.code to mens-trt, and requested_product to the medicine the patient selected.

symptoms is one or more option values. trt_intro is display only. Leave it out of answers. recent_labs uses Yes and No. Show recent_labs_value only when recent_labs is Yes, and send the most recent total testosterone and the approximate date.

{
  "external_ref": "consult-trt-1001",
  "patient_ref": "acme-patient-90210",
  "questionnaire_type": "trt",
  "requested_product": "testosterone-men-s-trt",
  "questionnaire": {
    "code": "mens-trt",
    "type": "trt",
    "answers": [
      { "id": "symptoms", "answer": ["Low Energy", "Low Sex Drive"] },
      { "id": "symptom_duration", "answer": "1 - 3 years" },
      { "id": "trt_familiarity", "answer": "I know some, but want to go deep" },
      { "id": "trt_goal", "answer": "More energy, focus, and confidence" },
      { "id": "recent_labs", "answer": "No" },
      { "id": "start_timeline", "answer": "Immediately" }
    ]
  }
}

Lab review consults

A lab review is a consult where a physician reviews the patient's lab results and writes back to them. The category slug is lab-review. The questionnaire code is lab-review.

Account requirement: lab reviews need Lab test files enabled on your account (see Lab test files). If it is off, a lab-review consult returns 403 lab_files_disabled.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/questions?category=lab-review" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

All five questions are free text (long_text).

At least one lab PDF is required. Send it in lab_files on POST /visits. A lab-review consult with no lab file returns 422 validation_failed with an error on lab_files. On PUT /visits/{id}, you may leave lab_files out to keep the stored files, but you cannot clear them with [].

requested_product is not needed. A lab review starts with no prescription.

{
  "external_ref": "consult-lab-1001",
  "patient_ref": "acme-patient-90210",
  "questionnaire_type": "lab-review",
  "questionnaire": {
    "code": "lab-review",
    "type": "lab-review",
    "answers": [
      { "id": "review_goals", "answer": "I want to know if my thyroid and iron levels explain my tiredness." },
      { "id": "review_questions", "answer": "Is my ferritin too low? Should I retest?" },
      { "id": "current_medications", "answer": "Vitamin D 2000 IU daily" },
      { "id": "allergies", "answer": "I don't have any allergies" },
      { "id": "lab_results_text", "answer": "TSH 3.9 mIU/L, ferritin 18 ng/mL, vitamin D 28 ng/mL" }
    ]
  },
  "lab_files": [
    {
      "url": "https://files.yourapp.com/labs/panel-2026-11.pdf",
      "filename": "panel-2026-11.pdf",
      "content_type": "application/pdf"
    }
  ]
}

What comes back. The physician writes the review in the patient letter and completes the consult. The consultation.approved webhook carries:

• data.patient_letter: the physician's review and recommendations, as plain text. It is also on GET /visits/{id}.
• data.prescriptions: [] when the physician did not prescribe. The physician may prescribe any product your pharmacy stocks. Those fills arrive here the same way as on any other consult.

Lab reviews are not billed for now. A prescription issued from a lab review is handled the same way as on any other consult.

Errors

Sample requests

Full POST /visits bodies for MICC + B-12 and Glutathione. Each body includes the patient, the product, and every answer that applies.

Consultations have three statuses. The JSON status field is the stored value:

Opening the consult in /prescriber may store in_progress; the status stays Open. needs_information, cancelled, and abandoned are not product statuses.

Partners may withdraw an Open consult only while it is still stored pending (cancelled on POST /visits/{id}/status). That is a partner API action, not a fourth consultation status.

PUT /visits/{id}

Update consult fields without changing status: clinic_id / nested clinic, practitioner_id, metadata, lab_files (see Lab test files), is_test (only while Open and stored pending). There is no notes field. A notes key on create or update is ignored and is not returned. Clinical comments belong in questionnaire answers. Status changes use the endpoints below. practitioner_id, metadata. There is no notes field. A notes key on create or update is ignored and is not returned. Clinical comments belong in questionnaire answers. consult_mode: "sync" turns an open async consult into a call consult; "async" on a sync consult returns 422. practitioner_id returns 422 while a call is booked: reschedule or cancel the call first. Status changes use the endpoints below.

POST /visits/{id}/status

Partners may only withdraw an Open consult while it is still stored pending:

{ "status": "cancelled", "reason": "Patient withdrew" }

Partners cannot set Completed or Declined. A Bespoke provider reviews and completes or declines in the consult UI. After a provider has opened the consult (stored in_progress) or closed it, partners cannot withdraw it.

Terminal states cannot be reopened. Creating a prescription never changes visit status.

POST /visits/{id}/complete

Not available to partners. Completing (approving) a consult is a Bespoke provider action.

POST /visits/{id}/cancel

Shortcut for { "status": "cancelled" }. Works only while the consult is Open and still stored pending. Optional body: { "reason": "…" }.

PUT /visits/{id}/questionnaire

Attach or replace the medical assessment on an existing consult (same questionnaire / questionnaire_type fields as create). POST to the same path is accepted as an alias. Clinical data stays on the visit for provider review and is never relayed to the pharmacy.

POST /visits/{id}/images

Attach optional clinical photos as partner-hosted HTTPS URLs. Send one or both:

Aliases also accepted: face / photo_id, or nested under images (images.face, images.photo_id, …). The same fields may be sent on POST /visits or PUT /visits/{id}.

Photos are not required to complete a consult. Re-submitting replaces the previous URL for that slot. Photos are clinical review data only — never sent to the pharmacy network.

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/visits/consult-1001/images" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "face_url": "https://cdn.partner.example/patients/pt-1/face.jpg",
    "photo_id_url": "https://cdn.partner.example/patients/pt-1/id-front.jpg"
  }'

Visit responses include:

{
  "images_complete": true,
  "images": {
    "face": {
      "slot": "face",
      "url": "https://cdn.partner.example/patients/pt-1/face.jpg",
      "uploaded_at": "2026-08-28T12:00:00+00:00"
    },
    "photo_id": {
      "slot": "photo_id",
      "url": "https://cdn.partner.example/patients/pt-1/id-front.jpg",
      "uploaded_at": "2026-08-28T12:00:00+00:00"
    }
  }
}

GET /visits/{id}/images/{slot}

Resolve one photo (face or photo_id) using the same API credentials. Responds with a redirect to the partner-hosted source_url.

GET /visits/{id}/messages · POST /visits/{id}/messages

Medical messaging thread for one consult (patient ↔ provider). Requires medical messaging enabled on your partner account (admin toggle; off by default).

POST body:

Provider replies in the Bespoke Message center; when webhooks are enabled you receive medical_message.created. Full contract: /docs/messaging.

GET /patients/{id}/messages · POST /patients/{id}/messages

Message a patient when there is no consultation. Create the patient with POST /patients first (include address.state, a two-letter US code). {id} is the patient UUID or your external_ref. Pass ?brand_code= when that external_ref exists on more than one brand.

The POST body is the same as a consult message:

201 response is one message object (message_id, direction, sender_type, body, attachments, sent_at, …). attachments is always an array of { "filename", "content_type", "url" }. It does not include a visit id.

GET returns only messages posted on the patient. Consult messages stay on GET /visits/{id}/messages.

{
  "patient_id": "3f2a1c8e-9b4d-4e6a-8f1c-2d7e9a0b5c4d",
  "external_patient_id": "acme-patient-90210",
  "visit_id": null,
  "external_visit_id": null,
  "messages": []
}

A prescriber licensed in the patient’s state can open the thread. The platform default provider can open every thread. If state is missing, only the default provider sees it.

When they reply, you receive medical_message.created. visit_id, external_visit_id, practitioner_id, and external_practitioner_id are null. Match the reply on patient_id or external_patient_id. sender_name is the prescriber. Full walkthrough: /docs/messaging.

GET /visits / GET /visits/{id}

List (filter ?status= / ?patient_ref= / brand) or retrieve one consult. ?status= uses the stored value (pending, in_progress, completed, declined). Product statuses are Open (pending / in_progress), Completed, and Declined. The visit response includes questionnaire_type, questionnaire, questionnaire_submitted_at when present, and is_test when the consult is a test consultation. The visit response includes questionnaire_type, questionnaire, and questionnaire_submitted_at when present. It also includes consult_mode and appointment (the booked call, or null).

Booked calls (video and audio)

A sync consult needs a live call with a prescriber. Requires video visits enabled on your partner account (admin toggle; off by default). Otherwise these endpoints return 403 video_visits_disabled. Booking never changes the consult status.

Calls are for categories that require them: TRT today. With video visits on, a consult with questionnaire_type: "trt" is sync on its own; consult_mode: "sync" for another category (for example glp-1) returns 422 on consult_mode. A consult with no category may still ask for a call.

A sync consult keeps a category that offers calls: changing questionnaire_type to one without calls, on POST /visits with the same external_ref or on /visits/{id}/questionnaire, returns 422 on questionnaire_type. While a call is booked, the consult also keeps its prescriber (422 on practitioner_id) and its patient (422 on patient, for example a repeated POST /visits with another patient): cancel the call first.

Flow: you ask for availability → show the patient the free days → the patient picks a day and a time → you book it → appointment.scheduled → appointment.reminder about an hour before. Only the patient picks the time: the prescriber does not book, move, or confirm calls; a booked call simply appears in their calendar. Bespoke sends no email or SMS to patients, so you notify and remind the patient.

Availability offers every day with a free slot, from today through the next 14 days, in the patient's time zone. Today counts once a slot is at least 2 hours away; a full day is left out. Weekends count only when a prescriber works them. Slot ids come for one day at a time: the nearest day, or the one you send in date. Calls are 5 minutes, one every 10 minutes (a 5-minute break after each). The slots are the hours of the consult's own prescriber, the one assigned when the consult was created (practitioner_id).

Changed on November 12, 2026: the slots used to come from every prescriber licensed in the patient's state, and booking could move the consult to the slot's prescriber. Now only the consult's prescriber offers slots, and booking never changes practitioner_id.

Changed on November 10, 2026: availability used to return only the nearest day after today. It now adds days and takes date, and offers today. The other fields are unchanged, so code that shows the one day it gets still works.

Booking keeps the consult's practitioner_id. booked_by is partner or admin (Bespoke staff on the patient's behalf). Every change, including system cancellations (prescriber time off, consult closed), sends an appointment.* webhook, and each booked call sends one appointment.reminder 60 minutes before it starts. Full contract: /docs/scheduling.

Joining the call

The patient joins from your website and stays on your page. You add one script and one backend route; the script shows the Bespoke call page inside your page and hands it a single-use ticket. Full guide, with backend examples in PHP and Node: /docs/joining-a-call.

<button id="join">Join your visit</button>
<div id="call"></div>

<script src="https://a-nirwan.bespoke-consults.designingit.co/video/embed.js"></script>
<script>
  async function getTicket() {
    const response = await fetch('/your-backend/call-ticket', { method: 'POST' });
    if (!response.ok) throw new Error('No ticket');
    return (await response.json()).ticket;
  }

  document.getElementById('join').addEventListener('click', () => {
    BespokeCall.mount(document.getElementById('call'), {
      callPageUrl: 'YOUR_CALL_PAGE_URL',
      getTicket,
      onEnd: () => { /* show the patient your next step */ },
    });
  });
</script>

• /your-backend/call-ticket is your own route: it calls the ticket endpoint with your API key, which stays on your server. Take the consultation from the patient's login, never from the browser. call_page_url is the same for every call on your account, so keep it in your settings.
• BespokeCall.mount(element, options) returns { destroy() }. Options: callPageUrl, getTicket() (a promise of the ticket, as a string), and optional theme, onState(state), onError(code), onEnd(). Give the element a height, at least 600px. onError codes: ticket_failed, page_not_loaded, invalid_ticket, network, rate_limited, unavailable.
• The join window runs from 10 minutes before the start to 30 minutes after the booked end. A call entered in time is not cut off then: it stays open 60 more minutes, and the patient can still get a ticket for it.
• The call shows only on websites Bespoke registered for your account, over https://. The ticket never goes in a URL.

Without the script: an iframe that loads call_page_url with allow="camera; microphone". The page sends bespoke-call:ready; you answer with postMessage { type: "bespoke-call:start", ticket, theme? } to the page's origin, with a new ticket each time it asks, or { type: "bespoke-call:no-ticket" } if you could not get one. It reports bespoke-call:state (for example waiting, in_call, ended) and bespoke-call:error (invalid_ticket, network, rate_limited, unavailable). No patient data in either.

POST /clinics

Create or update a clinic under your brand. Upserts by external_ref when provided.

Response includes clinic_id, external_ref, brand fields, name, phone, address.

GET /clinics / GET /clinics/{id}

List or retrieve clinics for your account. Lookup by clinic_id UUID or external_ref.

POST /practitioners

Create or update a provider / practitioner. Upserts by npi under the brand. Which consults they can review depends on state licenses, not on a clinic.

Response includes practitioner_id (internal public uuid), external_ref, NPI, name, phone, address, and licenses.

New consults are assigned automatically by the global state round-robin across every active provider with a valid license for the patient's state, regardless of company association. A submitted practitioner_id does not override creation-time rotation; use PUT /visits/{id} for an explicit reassignment. Completing a consult requires a provider. Prescriptions linked to a visit always use that visit's assigned practitioner, even if the prescription payload contains a different prescriber.

GET /practitioners / GET /practitioners/{id}

List or retrieve practitioners. Lookup by practitioner_id UUID or external_ref.

Prescriptions

Partners cannot create prescriptions via the API. When a Bespoke provider approves a consult, Bespoke creates the fills for that visit (count is set on your account). Use GET to list and poll those submissions.

GET /prescriptions/{submission_id_or_external_prescription_id}

Retrieve one submission by Bespoke submission_id (UUID) or your external_prescription_id (stored as external_ref). Optional ?brand_code= / ?brand_id= when looking up by external id under a multi-brand account.

Fetch one submission by Bespoke submission_id (UUID) or your external_prescription_id.

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/prescriptions/b4f0c1d2-9a76-4a1e-8f3b-2c5d7e9a0b11" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

200 OK (shipped example)

{
  "submission_id": "b4f0c1d2-9a76-4a1e-8f3b-2c5d7e9a0b11",
  "status": "shipped",
  "is_test": false,
  "patient_ref": "acme-patient-90210",
  "medication": "Semaglutide",
  "strength": "0.25mg",
  "quantity": 4,
  "refills": 0,
  "tracking": {
    "carrier": "UPS",
    "number": "1Z999AA10123456784"
  },
  "timeline": [
    { "status": "queued", "at": "2026-08-12T11:14:03+00:00" },
    { "status": "accepted", "at": "2026-08-12T11:14:19+00:00" },
    { "status": "shipped", "at": "2026-08-13T16:02:44+00:00" }
  ],
  "created_at": "2026-08-12T11:14:03+00:00",
  "updated_at": "2026-08-13T16:02:44+00:00",
  "metadata": {
    "your_order_id": "ACME-88213"
  }
}

200 OK (failed example)

{
  "submission_id": "b4f0c1d2-9a76-4a1e-8f3b-2c5d7e9a0b11",
  "status": "failed",
  "patient_ref": "acme-patient-90210",
  "medication": "Semaglutide",
  "strength": "0.25mg",
  "quantity": 4,
  "refills": 0,
  "error": {
    "code": "pharmacy_rejected",
    "message": "Prescriber NPI is invalid. Fields: {\"prescribedBy.npi\":\"must be a valid NPI\"}"
  },
  "timeline": [
    { "status": "queued", "at": "2026-08-12T11:14:03+00:00" },
    { "status": "failed", "at": "2026-08-12T11:14:25+00:00" }
  ],
  "created_at": "2026-08-12T11:14:03+00:00",
  "updated_at": "2026-08-12T11:14:25+00:00",
  "metadata": {
    "your_order_id": "ACME-88213"
  }
}

error.message is actionable detail from the pharmacy network (vendor product names removed). Use it to understand why fulfilment failed.

404 — unknown id, or a submission that belongs to another account / outside retention.

Pause and activate fills (pharmacy routing required)

These endpoints work only when pharmacy routing is activated on your account so prescriptions go through the Bespoke pharmacy channel (admin: Route to pharmacy network).

If routing is off, or your account is set to return prescriptions to you (partner_return), pause and activate are not available. Those calls return 403 pharmacy_channel_required. Ask your account manager to turn on pharmacy routing if you need this.

The consult must already be completed. Shipped and delivered fills cannot be held.

POST /visits/{id}/prescriptions/pause

Hold remaining fills on a completed consult (pharmacy routing must be on).

Queued fills are held in Bespoke and are not relayed. Accepted (not yet shipped) fills are cancelled at the pharmacy and marked paused. Shipped and delivered fills are skipped.

For is_test consults, Bespoke also schedules pharmacy cancellation (default 1 minute after accepted on the live pharmacy connection). You may still call pause sooner as a backup (see Test consultations).

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/visits/VISIT_ID/prescriptions/pause" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"reason": "Patient asked to hold remaining fills"}'

Optional prescription_id (UUID or your external_prescription_id) limits the call to one fill. reason is optional.

200

{
  "visit_id": "…",
  "action": "paused",
  "updated": 2,
  "unchanged": 0,
  "skipped": 1,
  "prescriptions": [
    { "submission_id": "…", "status": "paused" }
  ]
}

403 pharmacy_channel_required — pharmacy routing is not activated for the Bespoke pharmacy channel (account is partner_return, or fills are not sent through us).

422 — consult is not completed, or every fill has already shipped / been delivered.

POST /visits/{id}/prescriptions/activate

Release paused fills. They return to queued and are sent to the pharmacy again. Fills that were accepted (and therefore cancelled at the pharmacy when paused) are submitted as a new pharmacy order.

Same optional prescription_id as pause.

curl -X POST "https://a-nirwan.bespoke-consults.designingit.co/v1/visits/VISIT_ID/prescriptions/activate" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

POST /prescriptions/{id}/pause and POST /prescriptions/{id}/activate do the same thing for a single fill and return that submission.

GET /prescriptions

List your submissions, newest first. Scoped to your account and retention window (default 90 days).

curl "https://a-nirwan.bespoke-consults.designingit.co/v1/prescriptions?status=failed&per_page=25" \
  -H "X-Api-Key: $BESPOKE_KEY" \
  -H "X-Api-Secret: $BESPOKE_SECRET" \
  -H "Accept: application/json"

{
  "data": [
    {
      "submission_id": "b4f0c1d2-9a76-4a1e-8f3b-2c5d7e9a0b11",
      "status": "failed",
      "patient_ref": "acme-patient-90210",
      "medication": "Semaglutide",
      "strength": "0.25mg",
      "quantity": 4,
      "refills": 0,
      "error": {
        "code": "pharmacy_rejected",
        "message": "…"
      },
      "timeline": […],
      "created_at": "2026-08-12T11:14:03+00:00",
      "updated_at": "2026-08-12T11:14:25+00:00",
      "metadata": {}
    }
  ],
  "meta": {
    "per_page": 25,
    "next_cursor": "eyJpZCI6NDgyMX0"
  }
}

Pass cursor=<next_cursor> for the next page. When next_cursor is null, you are done.

Status lifecycle

queued → relaying → accepted → shipped → delivered
                 ↘ failed
                          shipped → voided
                 (pharmacy or admin) → cancelled

Polling guidance

• Poll no more than once per minute per submission.
• Most submissions reach accepted within seconds when the queue is healthy.
• shipped typically follows within a business day once fulfilment starts.
• After failed, do not keep polling the same id for recovery.

Errors

HTTP error shape

All API errors use one envelope:

{
  "error": {
    "code": "validation_failed",
    "message": "The submission could not be processed because some fields are invalid.",
    "request_id": "5c2a1f80-6f0e-4d3a-9d1b-77a0c2e6b4f9",
    "fields": {
      "patient.date_of_birth": ["Must be a valid date in the format YYYY-MM-DD."],
      "prescription.quantity": ["Must be greater than zero."]
    }
  }
}

fields appears only on 422 validation_failed.

HTTP status codes

Submission-level failure codes

These appear on a failed submission under error.code:

Read error.message for fulfilment failures.

Recommended integration flow

1. Call GET /ping from your deploy pipeline with sandbox credentials.
2. Optionally GET /products (or /medications) to pick catalog ids.
3. Optionally POST /patients once per person (upsert by your external_ref).
4. POST /visits with questionnaire (photo URLs optional; lab_files when Lab test files is enabled); later PUT /visits/{id}.
5. For a call consult (TRT with video visits enabled): GET /visits/{id}/availability, the patient picks a time, POST /visits/{id}/appointment; handle appointment.* webhooks; when the call starts, POST /visits/{id}/video/patient-ticket and show the call on your page (see Booked calls).
6. A Bespoke provider reviews and approves the consult. Bespoke then creates the prescriptions.
7. Poll GET /prescriptions (filter by patient_ref) or GET /prescriptions/{id} until terminal status.
8. If failed, show error.message to your operators.

Minimal happy-path sequence

GET  /v1/ping
GET  /v1/products               → catalog (optional)
POST /v1/patients               → 201 (optional; upsert by external_ref)
POST /v1/visits                 → 201 Open / stored pending (+ questionnaire; photo URLs optional)
                                  provider approves consult
GET  /v1/prescriptions          → fills created on approve
GET  /v1/prescriptions/{id}     → status=relaying | accepted | …
GET  /v1/prescriptions/{id}     → status=shipped (+ tracking)
GET  /v1/prescriptions/{id}     → status=delivered

Live pharmacy smoke test (test consultation)

Use only with Test consultations enabled and fictional test patients — not for production patient traffic.

POST /v1/visits                 → 201, is_test: true
                                  provider approves consult
GET  /v1/prescriptions          → fills created on approve, is_test: true
GET  /v1/prescriptions/{id}     → status=accepted
                                  after delay, Bespoke requests pharmacy cancel (queue workers required)
POST /v1/prescriptions/{id}/pause → optional backup
GET  /v1/prescriptions/{id}     → status=paused | cancelled

Partner dashboard

In addition to the API, your team can sign in to the partner dashboard to:

• View Patients, Visits / consults, Assessments (questionnaires), and Prescriptions
• Browse Products, Brands, Clinics, and Practitioners
• Inspect failure messages and submission status history
• Rotate API credentials

Dashboard access is separate from API keys (email/password for your users). Ask your account manager to invite operators.

Sandbox vs live

Use sandbox credentials until your payloads consistently reach accepted. Then switch to live keys and the production base URL your account manager provides.

To exercise real pharmacy relay without a production patient order, use a live key (or as directed by your account manager), enable Test consultations, send is_test: true, and follow Test consultations.

Integration checklist

• Credentials stored in a secret manager (never in source control)
• All calls made server-to-server over HTTPS
• Consults submitted with questionnaire (photo URLs optional)
• For call consults: availability → book flow built, appointment.* webhooks handled, call embedded on your page (see Booked calls)
• X-Request-Id captured in your logs
• Retries with backoff on 429, 500, and 503
• Polling capped (≤ 1/minute per submission)
• Tested end-to-end against sandbox before go-live
• Live pharmacy smoke tests use is_test: true, fictional patients, and pause after accepted when Test consultations is enabled

Support

Contact your account manager, or email support@bespoke.example.

Always include:

• submission_id and/or request_id (X-Request-Id)
• Approximate time of the request (UTC)
• Whether you are on sandbox or live