> ## Documentation Index > Fetch the complete documentation index at: https://docs.tagada.io/llms.txt > Use this file to discover all available pages before exploring further. # Building blocks > The decoupled Rx architecture: every storefront — Tagada-hosted template, headless site, or partner infrastructure — is a facade over the same small set of Rx bricks. # The Rx building blocks Tagada Rx is **decoupled by design**. The clinical flow is a small set of backend bricks — products, quizzes, orders, intakes, patients, cases, portal, refills — and every storefront is just a *facade* that calls them in some order. The [Tagada-hosted templates](/developer-tools/rx/storefront-templates) use the exact same bricks as a fully headless integration on your own infrastructure: nothing in the clinical layer is template-only. ```mermaid theme={null} flowchart TB subgraph FACADES["Facades (pick any — or several)"] direction LR F1["Tagada-hosted template
(Plugin SDK)"] F2["Your own site / funnel builder
(Headless SDK)"] F3["Your backend or a partner platform
(Node SDK / REST)"] end subgraph BRICKS["Rx bricks (invariant)"] direction LR B1[Products &
offerings] B2[Checkout &
orders] B3[Medical intake
questions] B4[Patients &
cases] B5[Patient
portal] B6[Refills &
ship-day rebill] end F1 --> BRICKS F2 --> BRICKS F3 --> BRICKS BRICKS --> NET["Clinical network + pharmacy
(Tagada-owned integration)"] ``` **Why this matters:** you can start on a hosted template today, move to a headless build on your own funnel infrastructure next quarter, and keep the same store, products, cases, and patient history. Switching facades is a frontend rewrite, never a data migration. *** ## The matrix: every brick, every surface | Brick | What it is | Storefront (browser) | Server (API key) | Endpoint | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------- | | **Product ↔ offering mapping** | "This product requires a prescription" — links a Tagada product to a clinical-network offering, with flags (`requiresIdVerification`, `requiresLabs`, `isDeaControlled`, `allowedStates`) | `rx.isRequiredForProduct(productId)` | `tagada.rx.setProductOffering(...)` to write it | `GET /api/public/v1/rx/required-for-product` | | **Marketing quiz** | Pre-payment qualification: vertical, goals, preferences. **Zero medical questions, zero PHI.** Lives in your storefront (template config or your own code) | Template quiz engine / your own UI — outputs product selection + tags | — (it's yours) | — | | **Checkout & order** | Standard Tagada commerce: session, payment, order, subscription | Plugin SDK `useCheckout`/`usePayment`, or Headless SDK `tagada.checkout` + `tagada.payment` | Node SDK `tagada.orders`, `tagada.subscriptions` | Standard checkout API | | **Medical intake questions** | Network-authored clinical questionnaire for a product, rendered verbatim post-payment | `rx.getQuestionsForProduct(productId)` | same via `tagada.rx` | `GET /api/public/v1/rx/questions-for-product` | | **Patient** | Identity + demographics. **Pass-through only** — transits to the clinical network, never persisted by Tagada | Part of the `submitCase` payload | Part of `tagada.rx.cases.submit` | — | | **Case** | The clinical unit of work (`rxcase_xxx`): submit → review → approve/decline → ship → deliver, with an append-only event timeline | `rx.submitCase({ orderId, checkoutToken, productId, patient, intakeAnswers })` | `tagada.rx.cases.submit / list / retrieve` | `POST /api/public/v1/rx/cases/submit` | | **Case status** | Authoritative status for the thank-you page and order tracking, proven by `(orderId, checkoutToken)` | `rx.getCasesForOrder({ orderId, checkoutToken })` — poll until terminal | `tagada.rx.cases.retrieve(caseId)` for the full timeline | `POST /api/public/v1/rx/cases/lookup` | | **Patient portal** | Case list, secure messaging, photo-ID upload. Auth = customer CMS session (email OTP) | Portal client over `/api/v1/rx/portal/*` (see [Patient portal](/developer-tools/rx/patient-portal)) | — | `/api/v1/rx/portal/*` | | **Refills & rebilling** | Ship-day rebill engine: next charge scheduled at `ship day + cycle`, automatically | — (invisible to the storefront) | `tagada.rx.cases.requestRefill(...)` for manual ops | `POST /api/v1/rx/cases/:id/refill` | | **Activation & config** | Integration lifecycle: activate, setup fee, clinical credentials, operating mode | — | `tagada.rx.requestActivation / confirmSetupFeePaid / configureBrandClinical / integrationStatus` | `/api/v1/rx/integration/*` | | **Affiliate terms** | Versioned commission contract (MoR mode); accruals post/reverse automatically | `accrualAmountMinor` returned by `submitCase` | `tagada.rx.setAffiliateTerms` (account-manager-restricted) | `/api/v1/rx/affiliate-terms` | Three auth models, one per column: * **Storefront calls** need no key — the case routes prove ownership with the `(orderId, checkoutToken)` pair your checkout already holds. * **Server calls** use a Tagada API key (`tagada.rx.*` in the [Node SDK](/developer-tools/rx/node-sdk)). * **Portal calls** ride the customer's CMS session (email OTP login). *** ## The same flow, on any facade Whatever the facade, a sale always executes the bricks in this order: ```mermaid theme={null} sequenceDiagram participant S as Storefront (any facade) participant T as Tagada participant N as Clinical network / pharmacy S->>T: required-for-product? (at product load) S->>S: marketing quiz (no PHI) S->>T: checkout + payment T-->>S: orderId + checkoutToken S->>T: questions-for-product S->>T: submitCase(patient, intakeAnswers) T->>N: create patient + case N-->>T: review / approve / ship (webhooks) S->>T: cases/lookup (poll) T->>T: schedule rebill at ship day + cycle ``` Two hard rules survive every facade: 1. **The marketing quiz and the medical intake are two different objects.** The quiz sells before payment and contains no medical questions; the network-authored intake runs after the card hold. If the clinician declines, the hold is voided — money never left the card. 2. **PHI is pass-through.** `patient` and `intakeAnswers` go from the browser through Tagada to the clinical network in one request. Never store them in your own database or queue them "for later". *** ## Funnel orchestration (Tagada-hosted facades) On Tagada infrastructure, each step of the journey is a **box in the Tagada funnel system** — a funnel step with its own `RuntimeStepConfig` (`resources`, `checkoutOffers`, `orderBumps`, `upsellOffers`, `pixels`, `paymentSetupConfig`), A/B-testable per step. The plugin manifest declares the remappable pages (`/`, `/checkout`, `/offer`, `/thank-you`) and the funnel engine drives transitions (`useFunnel().next`). Headless facades keep the same *logical* steps but orchestrate them themselves — the bricks don't care who drives navigation. See [Storefront templates](/developer-tools/rx/storefront-templates) for how the hosted templates arrange the boxes, and [With the Headless SDK](/developer-tools/rx/headless-sdk) for the self-orchestrated version. *** ## Where to go next The hosted template catalog: three archetypes, one skeleton, live demos. The same bricks from your own infrastructure — `tagada.rx` in the browser. Server-side: activation, config, product mapping, case ops. Running Rx for a fleet of merchants under your own brand.