Chia Health — affiliate integration quickstart

Version 1.1 · Contract: chia-s2s-v1 · What changed

This document describes tracking and reporting only: how Chia records your clicks, how we tell your tracker what your traffic did, and what analytics you receive. Commercial rates, settlement basis, and payment schedule are agreed separately and are not described here. Nothing in this document is an offer, a statement, or an invoice, and no figure in it is money owed to you.

Chia runs its own advertiser-side tracking. There is no third-party network in the data path. You send traffic to a Chia link; we record the click before the landing page renders; and, when enabled, we call the postback URL you supplied.

1. Start here: six answers, then a working link#

You do not need a finished tracker integration to get a link. You need six answers — four about who you are, two about where each asset points — and none of them are about postbacks.

{
  "schema_version": "chia-affiliate-onboarding-v1",
  "affiliate": {
    "code": "partner_demo",
    "name": "Example Partner",
    "contact_name": "Integration Owner",
    "contact_email": "integrations@example.com"
  },
  "assets": [
    { "destination_path": "/glp1", "offer_slug": "chia_internal_asset_01" }
  ]
}

That is the entire mandatory intake, and it is a real file you can copy: affiliate-api-onboarding.example.json.

Send it through Chia's approved secure channel. Chia returns, in one bundle:

• your affiliate_id,
• an active test link_code per asset,
• a list of what is still outstanding and what each item is blocking.

Ask for your read-API key and secret at the same time. They are issued as soon as your affiliate record is active — they do not wait on a postback test, so a partner who only reads reporting can be finished at this step.

Now click your test link and your redirect integration is done:

https://chia.health/go/<link_code>?click_id={YOUR_CLICK_ID}&sub_id={SUB1}

The click is recorded against your affiliate and the visitor lands on the offer. Because this is a test link, the click stays in test mode and never enters production reporting (§9). Nothing else is required to reach this point.

1.1 What you can send later#

Everything else in this document is optional at this stage and can be supplied on a later run of the same intake document. Deferring an answer never costs you an issued code: your link_code and affiliate_id are stable across reruns, and a rerun that only fills in blanks is accepted.

Two properties make deferral safe rather than merely convenient, and both are mechanical rather than procedural:

• An unconfigured postback cannot fire. Delivery selection requires a

non-empty template, so an absent template is not a postback that might be sent to the wrong place — it is a postback that cannot be selected for sending at all.

• Compliance is enforced where it was always enforced. A production link is

activated only with complete approval evidence, both disclosure confirmations, an active affiliate, a partner-confirmed postback contract, and an audited operator action. Sending less at intake does not soften that gate; it only means the production link is not minted yet.

Answers you have already given are not silently rewritten. A rerun may fill a blank, but changing an answer Chia has already issued against is refused, and a material postback change invalidates prior receipt confirmation and turns live delivery off until a new real-link test succeeds.

1.2 The full go-live sequence#

1. Chia issues an affiliate_id and an active test link_code per approved

asset, from the intake above.

1. You supply your separate HTTPS test and live postback URLs and the tracker

answers in §7.1, whenever your receiver is ready.

1. Your tracker opens the issued test link once with a real, unique click ID.

Chia verifies that exact qualified click and fires synthetic registration then purchase events against it. No card, patient, or production report is created.

1. You confirm receipt of both events. Chia binds that confirmation to the

tested configuration before enabling your live endpoint.

1. You supply the asset approval evidence and disclosures. Chia mints the

production link_code and activates it under the audited operator action described in §1.1.

Live delivery is disabled until step 4. Events queue while it is disabled and replay when it is enabled.

2. Inbound links#

Only this form is supported:

https://chia.health/go/<link_code>?click_id={YOUR_CLICK_ID}&sub_id={SUB1}&sub_id2={SUB2}

Direct links to a landing page are not supported. A link_code binds your affiliate, offer, destination, test/live mode, and approved asset.

2.1 Parameters#

Accepted aliases for click_id are clickid, cid, transaction_id, subid, tid, aff_click_id, cnv_id, and xid. s1–s5 alias sub_id–sub_id5. Do not use sub1 as a click-ID alias.

Do not send affiliate_id on an inbound link. The issued link_code owns the affiliate identity; an inbound value cannot select or override an affiliate.

An invalid click ID is recorded, flagged param_too_long or param_invalid_chars, and alerts Chia. It cannot match a conversion. An invalid sub-ID is stripped and named in reporting; the click remains fully trackable and convertible. There is one edge exception: a query value ending in .bak, .backup, .cfg, .conf, .config, .ini, or .log is rejected by Chia's Web Application Firewall before tracking, so the entire request returns 403 and creates no click. Do not use those suffixes in a click ID, sub-ID, or any other query value.

Do not use gclid, gbraid, wbraid, fbclid, ttclid, msclkid, utm_*, or ref for affiliate identifiers. They belong to separate Chia attribution rails and some are stripped by browser or messaging privacy features.

2.2 Redirect response#

• HTTP 302 to the approved offer path.
• `Set-Cookie: chia_aff=…; HttpOnly; Secure; SameSite=Lax; Domain=.chia.health;

Max-Age=2592000` on an accepted click.

• cache-control: no-store on every response.
• Unknown or revoked codes that reach the application still redirect to a safe

offer page; they never return an application 404. An edge security rule can reject a malicious request before the redirect runs.

• Repeating the same redirect within 60 seconds reuses the click record.

3. Approved offers#

There is no public, fixed offer-ID catalog in this contract. Each issued link bundle names the exact approved destination and the exact opaque value that its {offer} macro emits. Chia mints that off_ identifier; it is unique to the issued link and contains no treatment, medication, destination, or marketing-copy semantics. Do not construct a destination or offer value from marketing copy, and do not reuse a link for another creative or placement.

Chia issues approved coupon codes per partner. Use only codes Chia issued to you. Applied codes are recorded and appear in purchase reconciliation.

4. What Chia reports#

Chia reports every first purchase made by a person attributed to your link: any plan length and both new and returning customers. Plan length is a reporting dimension, never a filter. Your onboarding record also states the zero-value policy: normally a fully discounted first purchase is reported with 0.00; if suppress_zero_value is enabled for your integration, it is not created as an affiliate purchase or postback.

Three internal rails are not reported as your purchase because the affiliate click did not cause them: a B2B clinic order, an order added manually by a Chia operator, and the deferred sibling subscription used internally to split a mixed-term cart. Daily reporting itemises each exclusion reason.

Renewals are recorded but not postbacked. Chia's multi-month plans are prepaid for the term and auto-renew: a six-month term covers 168 days and a four-month term covers 112 days because Chia bills in 28-day months. Renewals and lifetime value appear in the daily CSV and monthly rollup, where tracker lookback windows cannot silently discard them.

Refunds and chargebacks are also recorded and reported with amount and date. They are not postbacked because they commonly arrive outside tracker lookback windows and trackers differ on whether later values replace or add.

5. Postback events#

There are exactly two same-session events. No renewal, reversal, cancellation, or third lifecycle event is sent.

Chia has no public sign-up. Accounts are created as part of checkout, so "created an account but did not pay" is not a separate state. registration means the qualification-quiz email submission—the real pre-payment signal in this funnel. It can precede checkout creation.

Your vocabulary is configurable as one mapping per event. The default mapping is registration → lead and purchase → sale. If your endpoint expects lead=registration and lead=payed&status=approved, supply those tokens on the intake form. They are words Chia renders for your tracker, not states Chia holds.

{sequence} increases per click. If you receive a lower sequence after a higher one, it is a retry of an earlier event, not a new event; do not let it overwrite a later state.

Chia's internal idempotency keys are not sent to partners. Deduplicate the same lifecycle fact using ({event}, {txid}); use {sequence} to preserve event order for one click.

6. Macro reference#

Every substituted value is percent-encoded. Unknown macros are rejected when the template is saved. {click_id} is mandatory.

{order_value} is the gross value of the customer's order. It is not your commission—{payout} is.

{payout} is the CPA agreed for the offer you promoted and the term the customer bought, resolved when the purchase is captured and fixed at that moment. A later rate change never alters a payout already sent to you. It renders 0.00—a real value, not a missing one—when the purchase does not qualify: nothing was collected, or the customer was not new to Chia.

{payout} is provisional when you receive it. It is sent at payment capture; commission validates over the window in your offer sheet, and a refund or chargeback inside that window reverses it. There is no reversal postback, so your tracker will not be told. Settle against /orders and the daily CSV, which carry refund state and remain the system of record.

Identity and clinical fields are unavailable: email, hashed email, phone, name, IP, user agent, patient identifier, medication, dose, condition, questionnaire answer, and treatment-revealing page URL.

7. Configuration#

7.1 Intake answers#

Only these are required to receive a link_code, as shown in §1:

1. affiliate.code, your legal/display name, and an integration

contact_name and contact_email.

1. Per asset, the exact destination_path and its offer_slug. The

offer_slug is Chia-internal, is never emitted to you in a postback or report, and must be unique within the document — it is how a rerun recognises a link it has already issued.

Everything below is optional at intake and may be supplied on a later rerun of the same document. It is listed here because you will eventually need all of it, not because you need it now.

1. Your tracker name and its click-retention/lookback window in days. Chia

requires at least two days of retry margin inside that window: a 32-day tracker window supports Chia's 30-day attribution default; a 30-day tracker window requires Chia attribution to be shortened to 28 days. This check runs whenever a lookback is supplied, whether at intake or later. If you send a lookback without an attribution window, Chia lowers the default to keep the margin rather than accepting a window your tracker would drop.

1. What your tracker does when the same click arrives twice with different

event names: update one row or create a second row.

1. Whether your tracker adds or replaces a value across postbacks for one

click. Binom's Upsell setting adds values, which is why registration is always 0.00.

Also send, when ready: event tokens, distinct live and test HTTPS postback URLs, the tracker authentication already embedded in each URL, whether you want registrations, your requested attribution window, your zero-value preference, and any literal failure-body text your tracker returns on a rejected conversion. For every requested production link, include the approved asset reference, approval evidence, and both required disclosure confirmations — these six are all-or-nothing, because an issued link is append-only and could never be given its approval evidence afterwards.

Any value you do supply is validated in full, immediately and unchanged: a postback template must still be HTTPS, still carry {click_id} in a query value, and still normalize to a different endpoint from its counterpart. Optional means deferrable, not unchecked.

Chia validates this as one onboarding record and returns the issued IDs and links as one bundle, along with a list of what remains outstanding and what each outstanding item is blocking. Re-running the same unchanged record is idempotent; a rerun may fill in a previously blank answer, but changing an answer already issued against is refused, and changing a material postback setting invalidates prior receipt confirmation and turns live delivery off until a new real-link test succeeds.

Use the onboarding JSON Schema, the minimal example, and — if you would rather send everything at once — the full example showing every optional field filled in. A completed intake may contain your tracker credential: transfer it only through Chia's approved secure channel, never commit it, paste it into a ticket/chat, or email it.

7.2 Transport#

• HTTPS GET with a query string. Plain HTTP endpoints are rejected.
• {click_id} must appear in a query parameter value. URL fragments are rejected

because browsers and HTTP clients do not transmit them to the tracker.

• Any 2xx, including 204, is success.
• A non-2xx response, timeout, or configured literal failure-body match is

failure. The failure text is not a regular expression.

• Timeout is one absolute 10-second deadline across DNS, connection, TLS,

request, and the bounded raw response read.

• Redirects are not followed.
• Authentication is yours: the credential embedded in your HTTPS query string

is the only v1 postback authentication mechanism. Never put it in URL user-info. To rotate it, submit updated test and live templates and repeat confirmation; Chia does not expose or return the credential.

• Test traffic can select only the separate test URL. Test and live templates

must normalize to different endpoints.

Chia retries with increasing backoff over roughly three days, then stops, alerts itself, and pauses your postback. Events remain queued and replay after re-enablement.

7.3 Example#

Template supplied by a partner:

https://tracker.example/postback?click_id={click_id}&affiliate_id={affiliate_id}&sub_id={sub_id}&sub_id2={sub_id2}&lead={mapped}&status={mapped}&order_value={order_value}&payout={payout}&currency={currency}&txid={txid}&seq={sequence}&security_token=THEIRS

Registration:

https://tracker.example/postback?click_id=a4f19c2b&affiliate_id=1234&sub_id=camp_a&sub_id2=creative_7&lead=registration&status=pending&order_value=0.00&payout=0.00&currency=USD&txid=a4f19c2b&seq=1&security_token=THEIRS

Purchase:

https://tracker.example/postback?click_id=a4f19c2b&affiliate_id=1234&sub_id=camp_a&sub_id2=creative_7&lead=payed&status=approved&order_value=1494.00&payout=150.00&currency=USD&txid=p_00194&seq=2&security_token=THEIRS

Send Chia your postback URL with your tracker's own parameter names already in it. Chia substitutes its macros; you do not rebuild your integration around a Chia-owned tracker template.

7.4 Mapping {order_value} and {payout}#

Send both. They answer different questions: {order_value} is what the customer paid, {payout} is what you earned.

If your tracker sums rather than replaces values for a repeated postback on the same click ID, a retry will double your recorded earnings. Tell us your tracker's repeat behaviour on the intake form and we will confirm the shape before live delivery is enabled.

8. Attribution#

1. The default window is 30 days.
2. Last affiliate click wins within the window, even if Chia already knows who

the visitor is.

1. Attribution binds to the person server-side at email capture or checkout.

It then survives a device change, cleared browser storage, and magic-link resume.

Chia's click, purchase, and renewal tables are the system of record for what happened. Your tracker is the system of record for what it received. If they disagree, an operator trace shows the exact attempted URL, HTTP status or fixed error_kind, elapsed milliseconds, and at most the first 512 decoded response characters retained for each attempt. Response headers and the remainder of the body are not retained. Because the attempted URL contains your tracker credential, Chia returns that trace only through an approved secure channel, never in an ordinary support email.

9. Test mode#

Test links send only to your test endpoint, carry {test}=1, and never appear in production reporting. A query parameter cannot turn a live link into a test link. During onboarding, first open the active issued test link with a real tracker click ID. Chia then locates that exact qualified test click and creates only synthetic registration → purchase facts against it, without a card or patient. If you have no test endpoint, Chia can use a built-in no-network mock sink for internal diagnostics, but mock acceptance never counts as partner receipt; live delivery remains blocked until your separate test endpoint receives and you confirm both events.

10. Reporting#

The daily CSV is emailed to the integration contact and has four sections.

A — day × sub_id optimisation: date, sub_id, sub_id2, raw_clicks, qualified_clicks, deduction_reason, registrations, purchases, new_purchase_value, renewals, renewal_value, total_value, refunds, refunded_value, net_value, click_to_purchase_cvr, and epc_on_order_value.

B — purchase reconciliation: timestamp_utc, click_id, sub_id, sub_id2, txid, term_months, order_value, net_collected, is_returning_customer, is_zero_value, offer, link_code, applied_coupon_ids, refund_state, refunded_amount, renewals_to_date, revenue_to_date, payout, and payout_status.

payout and payout_status are appended at the end of the row, after revenue_to_date, so a positional parser written against an earlier version of this document keeps reading every column it already knew at the same index. payout is the gross CPA for that purchase; it is not netted against refunded_amount, which is its own column two places to the left. A partner summing payout without subtracting refunded orders will overstate earnings. applied_coupon_ids is a compact JSON array containing every captured opaque discount, promotion, or coupon ID in stored order; [] means none.

C — exclusions: counts for b2b_partner_rail, admin_added, and deferred_sibling.

D — refund/chargeback adjustments: timestamp_utc, adjustment_id, click_id, purchase_txid, sub_id, sub_id2, applies_to, renewal_cycle, adjustment_type, net_value_adjustment, currency, offer, and link_code. One append-only row appears for each refund, chargeback, or chargeback reversal. Negative adjustments reduce net value; positive adjustments restore it.

Chia sends both UTC and America/New_York daily variants after 06:00 UTC, when both prior local days have closed. The subject names the date and timezone. Automated catch-up considers the most recent seven daily dates and three monthly periods, oldest unsent first; support explicitly regenerates older gaps under their original date rather than relabelling them as current. The monthly rollup groups by sub_id and cohort month and includes purchase and renewal value, revenue per acquired customer at days 30/60/90/180, refund/chargeback rate, and median click-to-purchase lag. It is a reporting document, not an invoice or statement; no number in it is a balance.

The exact CSV schemas, reversible opaque-text encoding, and synthetic samples are in the affiliate CSV reporting contract.

Sub-ID revenue comes from this reporting, not GA4. GA4 cardinality limits, privacy thresholding, sampling, and client-side event loss make it unsuitable for transaction reconciliation.

A read-only JSON API over these same facts exists and is in limited pilot. It answers the two questions this reporting rail cannot answer quickly — per-order refund state and chargebacks — without waiting for the next morning's email, and it can return the exact daily and monthly artifacts themselves, either as structured JSON or as the byte-identical CSV. It publishes nothing beyond what this document already describes. A credential is issued by your named Chia integration owner; there is no self-service issuance and no general-availability date, and until one is issued to you every endpoint answers 401 and the emailed CSV remains your reporting rail. The endpoints, objects, cursor grammar, and boundaries are in the affiliate read API contract.

A partner dashboard is not part of this integration.

11. Data boundary#

Chia is a telehealth provider. Postbacks contain opaque tracking/order references, event vocabulary, order value, sequence, and time only. Chia does not transmit identity or clinical data, even hashed. This is enforced mechanically: the URL-rendering function has no access to a customer record.

Do not attempt to re-identify Chia customers, enrich conversion data against other datasets, or sell, license, or onward-transfer it. See the companion program terms.

12. Known attribution loss#

• Chia uses a server-set redirect cookie so Safari's JavaScript-cookie limits

do not apply to the standard link.

• Click recording occurs inside the redirect and does not depend on ad scripts.
• Cross-device journeys that never reach email capture or checkout cannot be

stitched.

• Chia will publish measured loss after two weeks of live data. We are not

going to quote you a number we made up.

Bot and scanner traffic that reaches Chia is excluded from qualified clicks and itemised as scanner_ua, datacenter, or no_user_agent. More than 60 requests in the same UTC clock-hour bucket for the same issued link and hashed client IP are redirected but not recorded; if the shared cache is unavailable, the database fallback counts the preceding rolling hour. Either way, excess requests are not itemised or counted. Partners testing behind one shared NAT must stay below that limit. Edge-blocked requests likewise never reach reporting.

13. Support and trace#

Email support@chia.health with subject [Affiliate integration] and the opaque click ID or transaction ID. Never include a name, email address, medical information, questionnaire answer, medication, or other patient data. The operator trace returns tracking timestamps and validated parameters, binding state, purchase and values, renewals, refunds, events, and each delivery attempt with the bounded evidence described in §8. Support uses email only to coordinate the request; credential-bearing trace output is transferred separately through an approved secure channel.

Error reference#

These are the actual fixed tokens visible in a Chia operator trace. The public /go redirect has no JSON error body: it normally returns 302, while an edge security rejection such as a forbidden suffix returns 403 before tracking.

Clicks but no conversions: confirm the inbound click_id is a real value, not a literal tracker macro.

Chia shows a conversion but your tracker does not: check the parameter names in your postback URL and request a trace. Chia does not publish a stable egress IP allowlist in this v1 contract; if your tracker requires an allowlist, resolve that requirement with Chia before activation.

Order value is 0.00: the event is a registration or the order is fully discounted; check is_zero_value in the CSV.

Payout is 0.00 but the order was real: read payout_status on the order in /orders or Section B. returning_customer and refunded are commercial outcomes; unresolved means Chia has not determined the amount yet and is worth raising with your contact.

14. What changed in this revision#

Nothing here breaks an existing integration. chia-s2s-v1 is unchanged: every macro you already use renders exactly as it did, and a postback template that does not mention the new macro is unaffected by this revision.

• New macro {payout} (§6, §7.4). Your commission for that purchase, in

dollars. Until now the only money macro was {order_value} — the customer's order total — so there was no way to receive your own earnings in real time. Read §6 on its provisional status before treating it as settled: it is sent at payment capture, a refund or chargeback inside the validation window reverses it, and there is no reversal postback.

• New /orders fields payout_cents and payout_status.
• Two new columns in Section B of the daily CSV (§10): payout and

payout_status. They are appended after revenue_to_date, never inserted, so a parser reading Section B positionally keeps working unchanged.

• payout_status explains a zero: zero_value (nothing was collected),

refunded (money had already gone back), returning_customer (the buyer was not new to Chia), or unresolved (not yet determined).

To start receiving the amount, add the macro to your postback URL under whatever parameter name your tracker expects and send Chia the updated template. Changing your template ends the current certification, so the two-step test fire in §9 is re-run before live delivery resumes.