Bind Quote

Binds a quote into a policy in a single, atomic call — the one-call convenience over hand-rolling a new-business transaction from the quote’s data. The quote is read server-side; the body is optional.

On success the quote is linked to the resulting policy (quoteStatus becomes bound, and the quote points at the policy) and the policy is created — both in one transaction, so a quote can never end up bound to a policy that was not created, or vice versa.

Which quote types can bind. The endpoint dispatches on the quote’s type, and all five types bind here. newBusiness and renewal mint a brand-new policy (a renewal’s new policy is linked back to the expiring term); endorsement, cancellation, and reinstatement transact against their existing source policy in place. The response policyId is the policy the transaction landed on — the new policy for newBusiness / renewal, the existing source policy for the in-place types.

Bindable states. A quote binds from inProgress or complete. A quote that is already bound returns 409 — the error body carries referencingPolicy (the policy it is already bound to) so you can recover the id without another call. A cancelled quote returns 409.

Validation. The quote must satisfy the same policy-create rules a new-business transaction enforces — notably the term bounds on the quote’s own policyStartDate and policyEndDate root fields, and a resolvable primary insured among its exposures. A quote that fails them returns a structured 400.

Invoice convenience. Send { "generateInvoices": true } to build an explicit invoice plan server-side from the resolved policy-invoice presets, then validate and post it through the same policy-invoice batch as any caller-authored plan. For in-place transactions it keeps existing active invoices and adds the difference; new-business and renewal terms start from zero. It uses the term start as the first due date and repeats monthly. Primary-insured payees resolve from the quote’s canonical framework party. A preset requiring a broker fails closed with 422 because the framework has no canonical broker/producer party; use a transaction endpoint with an explicit invoicePlan and payeeId instead. Omit the body (or send {}) to preserve ordinary bind behavior with no invoices.

Required permission: company.policy:create