LFI-Led Flow 5 min read
The TPP creates a quote and hands the customer to your LFI on accept. Your LFI hosts customer verification, payment, and document delivery; the TPP’s only role after acceptance is to observe lifecycle events through the quote-log.
LFI-Led flow
Underwrite and return one or more quotes
The Hub validates the TPP’s access token, signed request, and schema, then proxies to your endpoint with the sector slug in the path. Receive the quote request, run your underwriting, and respond with 201 + data: [...] for one or more quotes, or 204 to decline.
QuoteId minting
Mint a unique QuoteId per quote — UUIDv4 is recommended. Persist it for at least the policy retention period of the sector. The QuoteId threads the rest of the lifecycle: TPP retrievals, the accept PATCH, policy creation, and every status event you emit to the quote-log.
Accept the quote — return 204
For LFI-Led mode, respond 204 No Content. You are signalling: the TPP has done its part; the LFI will drive everything from here. Then immediately PATCH the quote-log with ApplicationPending so the TPP (subscribed or polling) sees the application has been registered.
The Subscription.Webhook object on the PATCH body is consumed by the Hub for its own event delivery to the TPP. Your LFI MUST NOT act on it — just emit quote-log status updates as normal, and the Hub fans them out.
Your LFI hosts the customer through to issuance
After PATCH Accept, your LFI presents the customer with the quote summary, KYC capture, and payment screens. These are entirely under your control — the Hub is not in the loop. See the User Journeys page for the screens you typically host.
The TPP’s view of progress comes from the quote-log events you emit at each transition. You can emit additional intermediate events with BrokerInstructions[].Reason explaining customer-facing status the TPP should surface (e.g. "Document upload required", "Awaiting payment confirmation").
Issue the policy
Once your hosted flow completes (KYC passed, payment confirmed), the TPP calls POST to create the policy. In LFI-Led mode the body is minimal — just the originating QuoteId:
{
"data": {
"QuoteId": "8a4f2d09-2c5b-4f88-b1b3-1f06f7e91a2e"
}
}
Run your standard policy issuance. Return 201 Created. The InsurancePolicyId is delivered to the TPP via the PolicyIssued event, not in this response body — this keeps the API symmetric with TPP-Led mode.
Emit PolicyIssued + InsurancePolicyId
Emit a Pending Completion event carrying the issued policy reference. In LFI-Led mode the documents stay with your LFI (you have already delivered them to the customer via your hosted screens), so only the InsurancePolicyId is needed.
{
"QuoteStatus": "PolicyIssued",
"InsurancePolicyId": "pol-2026-000457"
}
Emit Completed and close the lifecycle
After any post-issuance work has settled (commission booked, customer onboarding emails sent), emit a final Completed Status event with the finalised premium breakdown and policy term. This is the terminal event — the Hub will reject any subsequent PATCH for this logId.
{
"QuoteStatus": "Completed",
"PolicyStartDate": "2026-06-01",
"PolicyEndDate": "2027-05-31",
"PolicyTerm": "P1Y",
"Premium": {
"OneYearPremiumExcludingVAT": { "Currency": "AED", "Amount": "950.00" },
"VATAmount": { "Currency": "AED", "Amount": "47.50" },
"TotalOneYearPremium": { "Currency": "AED", "Amount": "997.50" }
},
"CustomerPaidInFull": true,
"PolicyCountrySubDivision": "Dubai"
}