Generate Quote from Policy (Stateless)

Returns the editable Quote data a transaction on an existing policy would start from — without persisting anything. No quote is stored, no quote number or id is allocated, no relationship is created, no audit row is written, and no token, draft session or retry receipt is minted. Generation is a pure read.

Use it to build your own transaction UI: generate, let your user edit the returned data, then either bind it by value with Bind Quote by Reference or by Value, or save it as a quote and bind that quote, as described below. Bound by value, everything the server needs travels in the request, so there is no state to keep between the two calls.

Changing a bound policy through a saved quote. An endorsement, cancellation or reinstatement can go through a quote of its own, as in the app, so that its bind replaces the policy’s invoices the way the quote’s invoicing says (Quote invoicing):

1. Generate the change’s draft here. Nothing is saved.
2. Save it with Create Entity (POST …/entities/quote): send the draft’s whole data with your edits applied (for an endorsement, change only the fields that change and keep the rest as generated), and set two fields the draft leaves null unless your Conversion Rules write them: referencingPolicy, the policy’s id, and the change’s date in endorsementEffectiveDate, cancellationEffectiveDate or reinstatementDate. Use the effectiveDate you generated with, written the way the quote writes policyStartDate, for example {"date": "2026-12-15", "timezone": "America/New_York"}. An endorsement generated with an endDate also sets endorsementEndDate; without it the endorsement runs to policyEndDate.
3. For an endorsement, rate the quote with Rate Saved Quote by Id, which returns the rating without saving it on the quote (a rating that fails is still a 200, with diagnostics and no data), and save the rating outputs from its data with Update Entity. Don’t rate a cancellation or reinstatement (it returns 400): its draft already has the pricing the platform derives.
4. Bind it with Bind Quote and {"invoices": "generate"}, or prepare its plan with the quote invoicing endpoints and bind with {"invoices": "saved"}.

Saving a change quote without referencingPolicy is refused. Without its change date it saves, but Generate Quote Invoices and Attach Quote Invoice Plan refuse it with 400 finv2-invalid-quote-transaction-metadata, and its bind returns 400. validationIssues reports neither field, because a bind by value takes the policy and the date from its own request.

What produces the data. Your company’s configured Conversion Rules for (POLICY_TO_QUOTE, the requested transactionType) are evaluated server-side against a single resolved segment of the source policy. Each rule writes one destination field on the Quote. The rules are part of your field-model configuration — what carries between a policy and a quote is authored and reviewable, not inferred.

The data is the finished draft. It has every field your Quote configuration declares, with every calculated field worked out as a save would, fullTermBillingInfo included (null while policy invoicing is disabled). A field nothing fills is null. A value that needs a saved quote, such as a generated quote number, is null until the quote is saved. Nothing is saved. quoteType is set from transactionType — ENDORSE gives endorsement, RENEW gives renewal, CANCEL gives cancellation and REINSTATE gives reinstatement — whatever your rules write, so calculated fields that read it are worked out for that transaction. A field you must supply that the draft lacks is reported in validationIssues and comes back null. If a value fails its field’s type check, the calculated fields are not worked out and the finding names the field.

Which segment of the policy is read, per transaction type — always against the policy’s latest committed version:

Four transaction types, and why NEW_BUSINESS is not one of them. This operation converts from a policy, and new business has no source policy to convert from. New business is fully supported at bind: compose the field bag yourself and post it, exactly as you do today.

Concurrency. sourcePolicy.policyVersion is the version the returned bag was derived from. Echo it as expectedPolicyVersion on the bind request and the bind is refused with a 409 if the policy moved while your user was editing. That is the entire concurrency contract — the server holds nothing on your behalf.

200 with findings vs. an error. The dividing rule is FIXABILITY, not severity. Anything your user can fix by editing the returned draft comes back as a 200 with entries in validationIssues and a usable data bag. Anything they cannot fix by editing — an unknown policy, a policy in the wrong state for the transaction, missing or failing Conversion Rules — is a structured error with no draft at all.

Conversion uses the company’s explicitly authored rules. Missing required configuration is an error; matching field names do not supply a fallback.

Required permission: the requested transactionType’s own permission — policy.endorse, policy.cancel, policy.reinstate or policy.renew. Generating is the read half of authoring that transaction.