API tokens are created and managed in Settings - API Settings. Each token is tied to a single portal user. Tokens can be rotated or revoked from that page at any time; revoked tokens stop working immediately.

Send the token in the Authorization header on every request:

Authorization: Bearer <token>

Tokens are scoped to your Clerk user account and start with lrx_live_. The full token is shown only once when you create or rotate it, so save it somewhere secure.

Returns leads collected for your partner account, ordered newest first. Paginated using a cursor; pass the nextCursor value from the previous response in the cursor query parameter to fetch the next page.

Self-hosted elective medication intakes create a lead progressively: account registration creates the row, and later intake steps can add phone and internal product/tier context to the same intake session. These rows use origin: "headless_intake" and location contains the configured product category. A row may therefore contain fewer contact fields on an early request and more when fetched again later. Product/tier context is not part of this public response.

**Elective-medication test runs are excluded by default.** Pass includeTest=true (see Query parameters) to include them. DNA, Care Services, and other lead sources are unaffected. See "Test and simulated data" for the two kinds of test run.

Envelope: { data: LeadRow[], page: { nextCursor, limit } }. If a lead has not consented to email or SMS, the matching email or phone field is returned as No Consent.

Two fields mark a test run from an elective medication intake: - isTest: true when the lead came from a test or simulated run rather than from a person. Always present; false on every real lead and on every lead recorded before test tagging existed. - testSource: why it is a test — "provider_test_mode" or "simulation" — and null when isTest is false.

Nothing else about a test lead is altered. origin still reads headless_intake, and the name and contact details are whatever was entered, because a mangled row is a row no later reader can trust. The flag is the only marker, so filter on it rather than on a name pattern.

Returns DNA test intake links available for your account. Requires DNA access; otherwise returns 403.

Envelope: { data: DnaProductLink[] }.

Returns medical intake product links assigned to your account. Pass sub to rewrite each link's partner_id to attribute orders to the given sub-account (1-250).

**Self-hosted intake forms.** Products configured for our self-hosted intake return a url in the form https:///?partner_id= instead of the older provider-hosted link, and report urlStyle: "headless". The previous link is still returned as legacyUrl, and both remain valid, so any URL you have already embedded keeps working. Products not yet configured, or where the override is switched off, return urlStyle: "legacy" with url and legacyUrl identical.

Headless links accept m=1|3|6 to preselect an available tier and preserve documented UTM/click attribution. Unsupported, duplicate, or invalid parameters are removed. Never append a patient name, email, phone, date of birth, questionnaire answer, token, or other patient data to an intake URL: the initial request can be recorded by hosting infrastructure before the form canonicalizes it. Headless forms can be embedded in an iframe; use your verified partner embedding domain where configured.

Envelope: { data: PartnerProductLink[], sub: string | null }.

Each link includes: - url: the link to share. Headless when configured, otherwise the legacy provider-hosted link. - legacyUrl: the provider-hosted link, always present so you can compare during the transition. - urlStyle: "headless" or "legacy".

Returns Care Service links available to your account. Results are filtered by active subscription/manual override, yearly-plan bundle access, individual service access, and category feature flags. URLs in the response are generated from the admin-configured Care Services base URLs; the examples below use placeholder domains.

Each result includes a default url (no duration pre-selected), a redeemUrl for Bulk Code Redemption, and a tiers array. Each tier contains a tier-specific url that already includes the matching m= query parameter, so you can hand the link directly to a patient without rebuilding it yourself.

The URLs are the same patient-facing checkout links rendered in the partner portal under Partner Links - Care Services. Patient-facing URL parameters appended to each link are documented in the "URL parameters" table below.

Envelope: { data: CareServiceLink[], sub, service, duration }. Admin-only catalog fields and pricing caps are not returned.

**Patient-facing URL parameters** (already appended to every url/redeemUrl we return - documented so you understand how to interpret or, if needed, regenerate them): - partner_id (always present): your partner attribution code. Required for revenue and order attribution. - m (optional, present on tier urls and when duration is requested): term in months. One of 1, 3, 6, 12. Pre-selects the matching tier on the checkout page. - sub (optional, present when sub was passed): sub-account number 1-250 for downstream attribution. - redeem=true (only on redeemUrl): switches the destination from the card-checkout flow to the Bulk Code Redemption screen. Patients enter a 12-character coupon code (no card collected) and we provision the membership directly. - lang (optional): accepted values are en and es. Returned URLs already carry the partner default when it is an enabled non-English language. An unrecognized or disabled value falls back to the partner default.

Download Care Services bulk coupon codes owned by the authenticated partner. Each coupon is single-use, locked to a productSlug + months combination, and either redeemed by a patient via your Bulk Code Redemption URL or marked void/expired. Admin tokens may filter by any partner_id; non-admin tokens are automatically scoped to their own partner.

Use this endpoint to programmatically pull every code you have purchased (including ones still in active status that have not yet been redeemed) so you can distribute them, store them in your own system, or reconcile redemptions.

Returns JSON by default. Pass format=csv to download a spreadsheet (the same columns as the "Download all CSV" button in the partner portal Bulk Orders view) instead.

JSON envelope: { data: CareServiceCoupon[], total, limit, offset }. Each coupon includes code (the raw 12-character A-Z 0-9 string), productSlug, months, status, expiresAt, redeemedAt, redeemedEmail, and redeemedLyricPrimaryExternalId so you can reconcile who used what.

CSV columns (with format=csv): code, product_slug, months, status, partner_id, sub_account_id, unit_price_cents, bulk_order_id, purchaser_email, purchaser_source, created_at, expires_at, redeemed_at, redeemed_email, redeemed_lyric_primary_external_id, notes. Values are quoted; embedded quotes are escaped by doubling.

Returns orders attributed to your partner account, including commission and shipping status. Sensitive fields are filtered for non-admin tokens.

**Orders from elective-medication test and simulated runs are included and flagged**, rather than withheld: an operator who ran one expects to see it. Every row carries isTest, and no row with isTest: true is ever paid — such rows are excluded from every payout and commission figure. Exclude them from your own revenue reporting the same way. DNA and Care Services orders are not produced by these test modes. See "Test and simulated data".

Envelope: { data: Order[] }. The order object matches the Orders UI fields: orderId, createdDate, subAccount, product, amount, commission, status, and isTest.

isTest is true for a test or simulated run and false for every real order, including every order recorded before test tagging existed. A simulated order additionally reports status: "Simulated" and an orderId prefixed with TEST-SIM-; it is synthesized from the run's own analytics events, reports zero commission, is never payable, and has no stored order behind it at all. The orderId of a real order is never decorated, because the payment and shipping updates for that order are matched against the stored id.

Test and simulation apply **only to elective medication intakes** — the self-hosted medical intake forms returned by GET /medical-intake-links with origin: "headless_intake" on the lead. DNA testing, Care Services, managed websites, and other lead sources do not have a product test mode or a ?test=true simulation path, and they never produce isTest: true rows through those mechanisms.

How to recognise elective-med activity that came from a test rather than from a patient, and how to keep it out of your reporting.

Test activity is **tagged, not hidden**. It appears in leads, orders, and analytics with a flag on the row, and it is excluded from every money figure we calculate. Suppressing it entirely would mean an operator who ran a test could not confirm it worked; leaving it unmarked would mean a fake patient reaching your CRM and a rehearsed sale reaching your revenue report. So the row is always there and always says what it is.

There are two kinds, and they are genuinely different things:

• **Test mode on the product.** An operator turns test mode on for a single elective medication product. The intake runs for real end to end and the treatment is created, but flagged so that it is never dispatched, prescribed, or fulfilled. The patient-facing form says so while it is on. Rows from these runs report testSource: "provider_test_mode".
• **Simulation.** Anyone opening an elective medication intake link with ?test=true walks the whole questionnaire without any of it being submitted anywhere. It is used to check a questionnaire change or rehearse a demo. No account is created, no card is collected, and the payment step is replaced by a "Simulate payment" button that issues no payment credentials of any kind. Rows from these runs report testSource: "simulation".

The distinction matters when you are reconciling: a provider_test_mode run has a real, non-fulfilled record behind it, while a simulation run has nothing behind it anywhere. Neither is a sale.

**What this means per endpoint:**

• GET /leads excludes test rows by default. Pass the includeTest=true query parameter (documented on that endpoint) to see them. Every row carries isTest and testSource either way.
• GET /orders includes them, flagged with isTest. A simulated order also reads status: "Simulated" and its orderId begins TEST-SIM-.
• Payouts and commission are never affected. No row with isTest: true is included in any payout or commission total, so a test run cannot inflate what you are owed or what you are shown as earning.

**If you sync either endpoint on a schedule, filter on isTest rather than on testSource, a name pattern, or an id prefix.** isTest is the field that answers "should this be counted"; testSource only explains why not, and an id prefix exists on simulated orders alone.

Both fields are on the lead row itself, so no extra request is needed to tell test activity apart:

• isTest (boolean, always present): true for a test or simulated elective-medication run. false for real activity, and false on every row recorded before test tagging existed, which is correct — those paths only ever produced real rows.
• testSource (string or null): "provider_test_mode" or "simulation", and null whenever isTest is false.

On orders, isTest is present and carries the same meaning; the reason is not exposed as a separate field there.

Returns payout records for the authenticated partner.

Envelope: { data: Payout[] }. Admin-only receipt and note fields are not included.

List, create, and delete sub-accounts. Sub-accounts let you attribute orders, leads, and links to a specific staffer or affiliate using the subId field.

GET envelope: { data: PortalSubAccount[] }. POST returns 201 with { data: PortalSubAccount }. DELETE returns { data: { ok: true } }.

Signature verification is optional, but strongly recommended. Every delivery includes an X-LegUpRx-Signature header in the form:

X-LegUpRx-Signature: t=<unix_timestamp>,v1=<sha256_hex>

The signed string is t + '.' + body, where body is the exact raw HTTP request body (do not re-serialize the JSON). Compute HMAC-SHA256 with your endpoint secret as the key and compare in constant time. Reject deliveries whose t is more than 5 minutes old to prevent replays.

We also send X-LegUpRx-Event (the event name) and X-LegUpRx-Delivery (a unique delivery id, useful for idempotent processing).

Active weight-loss products available for distribution.

These endpoints are unauthenticated. To attribute traffic to your account, distribute intake links that already include your partner_id, for example:

https://www.telehealthintakeforms.com/api/weight-loss?partner_id=RFMLPVN1

Typical response headers include Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate with Cdn-Cache-Control: no-store; Access-Control-Allow-Methods: GET, OPTIONS; Access-Control-Allow-Headers: Content-Type.

Active men's health products.

These endpoints are unauthenticated. To attribute traffic to your account, distribute intake links that already include your partner_id, for example:

https://www.telehealthintakeforms.com/api/mens-health?partner_id=RFMLPVN1

Typical response headers include Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate with Cdn-Cache-Control: no-store; Access-Control-Allow-Methods: GET, OPTIONS; Access-Control-Allow-Headers: Content-Type.

Active women's health products.

These endpoints are unauthenticated. To attribute traffic to your account, distribute intake links that already include your partner_id, for example:

https://www.telehealthintakeforms.com/api/womens-health?partner_id=RFMLPVN1

Typical response headers include Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate with Cdn-Cache-Control: no-store; Access-Control-Allow-Methods: GET, OPTIONS; Access-Control-Allow-Headers: Content-Type.

Active hair-loss products.

These endpoints are unauthenticated. To attribute traffic to your account, distribute intake links that already include your partner_id, for example:

https://www.telehealthintakeforms.com/api/hair-loss?partner_id=RFMLPVN1

Typical response headers include Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate with Cdn-Cache-Control: no-store; Access-Control-Allow-Methods: GET, OPTIONS; Access-Control-Allow-Headers: Content-Type.

Active wellness and longevity products.

These endpoints are unauthenticated. To attribute traffic to your account, distribute intake links that already include your partner_id, for example:

https://www.telehealthintakeforms.com/api/wellness?partner_id=RFMLPVN1

Typical response headers include Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate with Cdn-Cache-Control: no-store; Access-Control-Allow-Methods: GET, OPTIONS; Access-Control-Allow-Headers: Content-Type.

Combined active medication link product catalog across all medication categories.

These endpoints are unauthenticated. To attribute traffic to your account, distribute intake links that already include your partner_id, for example:

https://www.telehealthintakeforms.com/api/all-products?partner_id=RFMLPVN1

Typical response headers include Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate with Cdn-Cache-Control: no-store; Access-Control-Allow-Methods: GET, OPTIONS; Access-Control-Allow-Headers: Content-Type.

Partners can embed their Care Services catalog on their own site with the iframe URL shown in their Care Services section. Treat that URL like a shareable tracking link, not a secret. The embedded view only renders services the partner can currently access and respects category feature flags.

Replace the placeholder src below with the Care Services embed URL copied from the partner portal. Do not build this from the API docs domain. The payment-link domain accepts a few query parameters:

• partner_id (required): your partner attribution code; auto-populated by the partner portal's "Copy URL" buttons.
• service: one of primary-care, urgent-care, mental-health, dermatology, veterinary-care. Filters the embedded catalog.
• m: term in months: 1, 3, 6, or 12. Pre-selects a duration on the intake.
• sub: optional sub-account number (1-250) to attribute the order to a downstream account.
• redeem=true: switches the page from the Stripe checkout flow to the Bulk Code Redemption screen. Patients enter a 12-character coupon code (no card collected) and we provision the care services membership directly. Use the "Copy Bulk Code Redemption URL" button on each Care Services row to generate this URL.

<iframe
  id="leguprx-care-services"
  src="PASTE_YOUR_CARE_SERVICES_EMBED_URL_HERE"
  style="width:100%;border:0;min-height:700px;border-radius:16px;"
  loading="lazy"
></iframe>
<script>
  window.addEventListener('message', (event) => {
    if (event.data?.type !== 'leguprx-api-docs-height') return;
    document.getElementById('leguprx-care-services').style.height = event.data.height + 'px';
  });
</script>