Skip to main content
POST
Approve Cancellation
Approve the pending cancellation created by Request Cancellation. Approval uses the final external reason you provide. An explicit reason replaces the request-time default, and an omitted internal reason preserves its stored value. An omitted, null or empty external reason defaults to the stored external reason when either reason-aware request intake or approval enforcement is enabled. If both are blank, the API returns a field-validation 422. With both controls off, submit a nonempty external reason array.

Final dates at approval

When approval enforcement is enabled, PAS re-evaluates the state-and-reason minimum from the approval day before approval and NOC generation. A delayed approval can lengthen the request-time dates. PAS preserves dates already later than the minimum, validates applicable general, AL, and canceled WC dates, and recalculates the final premium values where dates change. Approved historical corrections with an attributable authorized exception retain their dates. Pure whole-policy insured_broker_request cancellations have no statutory notice minimum; legacy courtesy/carrier documents, emails, and filing work can still occur. They return notice_minimum_required: false with null floor_days and minimum_date. Applicable dates still require validation within the policy term. Mixed or unknown reasons remain subject to the conservative notice rule; partial NOC generation always applies the minimum. The success response adds the actual stored ISO YYYY-MM-DD general, AL, and WC dates and cancellation_notice metadata. wc_action identifies canceled, retained, or not-applicable WC. Null dates require coverage context; do not infer that coverage is absent or substitute a requested date. Keep the request dates as provenance and use final stored dates for notices and lifecycle clocks. Read final premiums from Submission Details after approval. A saved request decision or an advisory proposal is not a substitute for the top-level stored dates. The request and approval controls are separate and default off. Approval-time enforcement, including replacement of the legacy missing-AL federal date default, begins only when the approval control is enabled. See cancellation rollout and final dates.

Holds and guarded approvals

HTTP 422 with reason_code: cancellation_notice_manual_review means the dates require manual review. For example, a minimum after expiration is held rather than clamped to expiration. Inspect error and cancellation_notice; resolve the hold before trying approval again. Existing guarded-cancellation requirements still apply. A guarded approval needs the exact cancellation_guard_id, affirmative cancellation_guard_acknowledged, and an attributable cancellation_guard_approval_comment. Guard authority and acknowledgement failures can return 403 or 409 separately from notice-date holds.

Saved approval with an incomplete notice handoff

An intent-backed notice handoff can fail after approval and its guard transaction have committed. That case returns HTTP 500 with reason_code: cancellation_notice_continuation_review, approval_saved: true, and notice_continuation containing its id, recorded phase, and specific reason_code. The response also includes the immutable cancellation ID, current submission status, actual stored ISO dates, and cancellation_notice metadata. It does not contain status: success. Preserve this receipt and contact Cover Whale for review or safe continuation recovery. Do not blindly retry cancel-approve: the existing approval is saved, and reapproval cannot safely repeat an uncertain filing or queue publication. A generic error-only 500 does not establish that approval was saved; inspect the receipt and reconcile the transaction before choosing a retry. A successful approval response also does not establish that documents are ready, the required print-chain handoff completed, or a notice was delivered. Execute Cancellation can return 409 while an existing intent’s notice readiness blocks finalization.

Authorizations

AccessToken
string
header
required

JWT returned as AccessToken by the /authentication endpoint (the Cognito ID token carrying the email claim). It expires after 3600 seconds.

Headers

AccessToken
string
required

Path Parameters

displayId
string
required
transactionId
integer
required

Body

application/json
cancellation_reason
string[] | null

Final external cancellation reason codes. Required unless reason-aware request intake or approval enforcement is enabled and this transaction has a stored external reason. When either control is enabled, omission, null or an empty array defaults to the stored external reason; both submitted and stored reasons blank returns field-validation 422. With both controls off, submit a nonempty reason array. Explicit values override the stored default. Send an explicit reason for compatibility across rollout states.

Example:
internal_cancellation_reason
string[] | null

Internal cancellation reason codes. An omitted or null value preserves the stored internal reason; an explicit nonempty reason array replaces it.

Minimum array length: 1
cancellation_reason_broker
string

Broker-provided cancellation reason

cancel_reason_others
string

Free-text cancellation reason

Maximum string length: 500
cancellation_guard_id
integer | null

Exact guard identity required when this cancellation is guarded.

Required range: x >= 1
cancellation_guard_acknowledged
boolean | null

Affirmative human acknowledgement required when guarded.

cancellation_guard_approval_comment
string | null

Attributable human approval comment required when guarded.

Maximum string length: 2000

Response

Cancellation approved; this response alone does not prove notice-document readiness or delivery.

status
string
Example:

"success"

submission_number
string
transaction_id
integer
submission_status
string
transportation_submission_id
integer

Immutable cancellation endorsement row ID. Keep it alongside transaction_id, which can be reused.

effective_date_transaction
string<date> | null

Actual persisted general cancellation date (YYYY-MM-DD). Use final approval dates for notices and lifecycle clocks.

effective_date_transaction_al
string<date> | null

Actual persisted AL cancellation date (YYYY-MM-DD), or null if no stored date is available. Determine applicability from coverage context.

effective_date_transaction_wc
string<date> | null

Actual persisted WC cancellation date (YYYY-MM-DD) when wc_action is cancel; otherwise null. Determine applicability from coverage context and the decision.

cancellation_notice
object

Persisted notice-rule decision or request history; otherwise an advisory preview. Properties vary by phase and hold. Actual persisted dates are the top-level response fields.