Bind Quote by Reference or by Value

Quote door by reference, value door by value (Invoicing a policy). By reference, the policy’s invoices come from the quote, which the bind’s invoices names as on Bind Quote; by value, they come from the request: the invoicePlan you send, or none.

Binds a policy transaction through your company’s configured Conversion Rules, in one of two forms — discriminated by the presence of quoteId in the body:

• By reference — { "quoteId": …, "invoices": … }: binds a persisted quote exactly like POST …/quotes/{quoteId}/bind, and invoices works the same: generate builds the invoices from the quote’s invoice settings, saved binds the plan saved on the quote, and leaving it out binds none, refused while the quote holds a plan. It answers with the full policy-version result the transaction endpoints return instead of the bare { policyId }.
• By value — { "transactionType": …, "data": …, "invoicePlan": … }: the caller sends the whole change, so it sends the invoicePlan too, or none. Nothing is inferred. It binds an unpersisted Quote field bag — typically one returned by POST …/quotes/generate and edited client-side. No Quote row is created or linked; the transaction lands directly on the policy plane.

What produces the policy writes. Your company’s (QUOTE_TO_POLICY, transactionType) Conversion Rules are evaluated server-side over { source: data, transaction }. NEW_BUSINESS and RENEW bind the converted bag as the new policy payload; ENDORSE diffs the converted destinations against the segment in force at effectiveDate — a destination no rule writes is left untouched. CANCEL and REINSTATE are lifecycle transactions: the platform derives their pricing itself. With invoicing enabled they store data.fullTermBillingInfo as sent (see Billing with invoicing enabled below); otherwise a data payload changes nothing beyond the framework rows.

Required policy fields come from the quote data. A policy field that no rule writes and no policy calculation fills has no value after the bind. A required policy field, such as policyNumber, therefore reaches the policy one of two ways: the Quote data carries a value that a rule copies, or your configuration calculates it at bind (for example, from a policy-number sequence). Export your configuration to see which applies to each field. When neither supplies a value, the bind returns 400 InvalidEntityShape naming the field (for example, 'policyNumber' is required but null). By value, include the value in data under the Quote field the rule reads (data.policyNumber for a rule that copies source.policyNumber). By reference, set it on the quote with Update Entity (PATCH …/entities/quote/{quoteId}) before you bind.

The server stores nothing between generate and bind. There is no draft session, token, or receipt. expectedPolicyVersion — echo it from generate’s sourcePolicy.policyVersion — is the ONLY precondition: when it is stated and the source policy’s version has moved, the bind is refused with 409 PolicyVersionConflict without performing the transaction. Consequently a duplicated by-value NEW_BUSINESS bind mints a second policy, exactly as a duplicated create-then-bind does today; deduplicate on your side or bind new business by reference.

Per-type field rules (by value). policyId and effectiveDate are required for every type except NEW_BUSINESS, which forbids them (its term comes from the bag’s own policyStartDate / policyEndDate). endDate is an ENDORSE-only optional window end. expectedPolicyVersion is forbidden for NEW_BUSINESS (no source policy to name).

Checks. The quoteId form runs the same checks as …/{quoteId}/bind. The by-value form keeps its existing transaction validation and financial-integrity rules; it creates no Quote resource.

Invoices. By reference, invoices works exactly as on …/{quoteId}/bind, with the same refusals, and the form takes no invoicePlan: put a plan you wrote on the quote first with Attach Quote Invoice Plan. By value, invoicePlan is the plan the policy transactions take, which Invoice plans describes; it commits atomically with the policy version, and a change that moves the billing an invoiced policy’s invoices add up to needs one. The by-value form takes no invoices. Either form’s invoices require invoicing to be enabled (otherwise 403 finv2-policy-invoicing-disabled).

Both forms use the company’s explicitly authored Conversion Rules.

Billing with invoicing enabled. Stores the quote’s or caller’s billing as stated, without scaling, restoring or carrying billing from the policy. A billed term must restate fullTermBillingInfo on ENDORSE, CANCEL and REINSTATE; omission or unstated billing returns 400 finv2-policy-billing-required. A change that voids every active invoice while any billing line still owes returns 400 finv2-policy-invoices-required. New terms and unbilled policies may have no billing. An uninvoiced policy may bind with billing and no invoices; existing invoices must still add up to it, as Invoice plans explains.

Billing with invoicing disabled. The policy stores null billing. A non-null fullTermBillingInfo in the by-value data, malformed or not, or held by the quote bound by reference, is refused with 403 finv2-policy-invoicing-disabled, and nothing is saved: send null or leave it out. Companies awaiting their billing migration keep their existing derivation and carry behavior while invoicing is disabled.

Required permission: quote.bind