Skip to main content

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.

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.
Party-scoped mode is enabled by Flabs for your account. Contact support to turn it on. Until then your account behaves as catch-all.

​
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.
StepCatch-allParty-scoped
List tests / packagesStandard branch pricePass a party → that party’s negotiated price
Create lead / bookingParty optionalMust attach a party
WebhooksOne webhook for the labOne webhook per party, events routed to the matching party

​
A party is one of

FieldMeaning
corporateUserA corporate / company / TPA identifier
organizationA doctor or hospital identifier (used on tests/packages calls)
referredOrganizationReferring doctor (used on lead/booking create)
referredHospitalOrganizationReferring 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

​
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. 
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. 
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. 
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 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.