> ## Documentation Index
> Fetch the complete documentation index at: https://developer.flabslis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Party-scoped (B2B)

> Build a doctor's CRM, a hospital portal, a wellness app, or a corporate health dashboard — every lead, booking, price, and webhook tied to a specific corporate, doctor, or hospital.

Use this mode when you operate on behalf of **referring parties** — a corporate, a doctor, or a hospital — and each one needs its own pricing and its own event feed. Typical builders are **a doctor's CRM, a hospital portal, a wellness app, or a corporate health dashboard**, where every lead, booking, price, and webhook must stay scoped to one party.

<Note>
  Party-scoped mode is enabled by Flabs for your account. [Contact support](mailto:hello@flabs.in) to turn it on. Until then your account behaves as [catch-all](/crm/introduction).
</Note>

## What changes vs. catch-all

In catch-all mode a party is optional. In party-scoped mode it is **mandatory** on every call that touches a price or creates an entry, and webhooks are split per party.

| Step                  | Catch-all               | Party-scoped                                                   |
| --------------------- | ----------------------- | -------------------------------------------------------------- |
| List tests / packages | Standard branch price   | **Pass a party** → that party's negotiated price               |
| Create lead / booking | Party optional          | **Must attach a party**                                        |
| Webhooks              | One webhook for the lab | **One webhook per party**, events routed to the matching party |

## A party is one of

| Field                          | Meaning                                                            |
| ------------------------------ | ------------------------------------------------------------------ |
| `corporateUser`                | A corporate / company / TPA identifier                             |
| `organization`                 | A doctor or hospital identifier (used on **tests/packages** calls) |
| `referredOrganization`         | Referring **doctor** (used on **lead/booking** create)             |
| `referredHospitalOrganization` | Referring **hospital** (used on **lead/booking** create)           |

Pass **one** party per call. On tests/packages use `corporateUser` **or** `organization`. On create you may attach a doctor, a hospital, and a corporate together.

## Flow

```mermaid theme={null}
flowchart TB
    A[POST /client/auth/token]
    B[GET /client/labs<br/>pick a branchID]
    C[GET /client/crm/tests<br/>?branchID=...&corporateUser=... or &organization=...]
    D[GET /client/crm/packages<br/>?branchID=...&corporateUser=... or &organization=...]
    E[POST /client/crm/lead/create<br/>+ integratorID + a party]
    F[Register one webhook per party<br/>POST /client/events/subscribe]
    G[Event fires → routed only to<br/>that party's webhook]

    A --> B
    B --> C
    B --> D
    C --> E
    D --> E
    E --> G
    F --> G
```

## 1. Get party-specific pricing

Pass the party on the tests / packages calls. The returned `cost` / `total` is that party's negotiated rate; tests with no special rate fall back to the branch price.

```bash theme={null}
GET /client/crm/tests?branchID=<branchID>&corporateUser=<corporateID>
GET /client/crm/packages?branchID=<branchID>&organization=<doctorID>
```

## 2. Create the lead or booking with a party

Send your `integratorID` (always required) **and** at least one party.

```json theme={null}
POST /client/crm/lead/create
{
  "branchID": "6530a4a6f1d2c8b7e9a12345",
  "integratorID": "EXT-LEAD-10231",
  "phase": "lead",
  "first_name": "Rahul",
  "contact": "9876543210",
  "age": 32,
  "age_type": "year",
  "corporateUser": "6530a4a6f1d2c8b7e9acorp1",
  "tests": [{ "test": "6530a4a6f1d2c8b7e9aabcde", "cost": 350 }]
}
```

Every party you pass is validated — it must exist and belong to the branch, otherwise you get `404`.

## 3. Register one webhook per party

When subscribing, attach the party the webhook is for. Events for that party's bills/leads are delivered **only** to its webhook.

```json theme={null}
POST /client/events/subscribe
{
  "labID": "6530a4a6f1d2c8b7e9a12345",
  "events": ["bill.completed", "lead.created"],
  "endpoint": "https://corp-a.example.com/flabs/webhook",
  "protocol": "https",
  "corporateUser": "6530a4a6f1d2c8b7e9acorp1"
}
```

See [Webhooks](/webhooks/introduction) for the event list and payloads.

## Rules to know

* **Party required** — tests/packages and create calls without a party return `400`.
* **One per party** — a party can have only one active webhook per event; a duplicate returns `409`.
* **Reading webhooks** — `GET /client/events/getAllEvents` and delete also take the party, and only act on that party's webhooks.
* Everything else — `branchID` scope, same-day duplicate `409`, 60 req/min — works exactly like [catch-all](/crm/introduction).