Approval overrides

An approval override marks a party compliant without a certificate: for everything or for one coverage. It can also apply to one project only. Under multi-factor compliance it can apply to one compliance factor. It is what the dashboard's "Mark Compliant" and override controls create.

The override entity

{
  "id": 3301,
  "party_id": 191537,
  "coverage_prefix": "wc",
  "factor_type": null,
  "signing_template_id": null,
  "project_id": null,
  "end_date": "2027-01-01T06:00:00Z",
  "notes": "Sole proprietor, no employees",
  "revoked": false,
  "active": true,
  "created_at": "2026-10-07T14:03:11Z",
  "updated_at": "2026-10-07T14:03:11Z"
}

On an account without multi-factor compliance, factor_type and signing_template_id are served null. On write, null (what you read) or a blank string is accepted and changes nothing; any other value is 403 feature_disabled with details naming the field, and nothing is written. An override keeps whatever scope it already has.

Fields of features your account does not use are present with an empty value.

GET /parties/:id/approval_overrides

The party's overrides, revoked and lapsed ones included, in the collection envelope.

POST /parties/:id/approval_overrides

Creates an override. Body: coverage_prefix, factor_type, signing_template_id, project_id, end_date, notes.

• coverage_prefix belongs to the insurance factor and signing_template_id to document_signing. Sent without a factor_type, each sets its factor (a coverage_prefix alone makes an insurance override). Sent with a different factor_type, it is 422 validation_failed naming the field: an override is never made wider than you asked.
• A blank factor_type or signing_template_id is 400 validation_failed naming the field: send null when you mean no value (a null factor_type makes an override for every factor).
• Your account does not use coverage overrides (enable_coverage_overrides): sending a coverage_prefix is 403 feature_disabled with details naming the field (null, or the stored value sent back unchanged, is accepted).
• Your account does not use multi-factor compliance (enable_multi_factor_compliance): sending a factor_type or a signing_template_id is 403 feature_disabled with details naming the field (null or a blank string is accepted).
• Your account does not use projects (enable_projects): sending a project_id is 403 feature_disabled with details naming the field (null, or the stored value sent back unchanged, is accepted).
• An override applies to one project only under project compliance (enable_project_compliance), as on the dashboard's override form: sending a project_id is 403 feature_disabled with details naming the field (null, or the stored value sent back unchanged, is accepted).
• The account's override policy is enforced: when the account requires an end date (or notes) on overrides, a missing end_date (or notes) is 422 validation_failed naming the field.
• A project_id you send must be one of your account's projects (422 naming it otherwise), as the dashboard's Project list offers.
• A signing_template_id you send must belong to your account (422 naming it otherwise).

Side effects: the party's compliance is recomputed at once, so the party can become compliant (Vendor Became Compliant, its webhooks, and the end of its open request's reminders). On an account with coverage overrides, the event recorded is Override Added, with your key as the actor. On an account without coverage overrides, the event recorded is Marked Compliant, with your key as the actor.

Response 201 with the entity. Errors: 403 feature_disabled, 404 (party), 422 validation_failed.

PATCH /approval_overrides/:id

Updates the fields you send, under the same rules as the create. A field you do not send is never changed, with one exception below. Sending a factor_type other than insurance clears coverage_prefix, and one other than document_signing clears signing_template_id; an update that sends no factor_type clears neither. An override with no factor_type and a coverage_prefix (created from coverage dates or an import) is an insurance override: sending a coverage_prefix to an override with no factor makes it one. The exception: an override with no factor_type and a coverage_prefix (or a signing_template_id) has its implied factor (insurance, or document_signing) written on any update that sends no factor_type, so clearing its coverage_prefix later can never leave an override for every factor. Compliance is recomputed. Response 200 with the entity.

The entity a GET serves can be sent back as read: members that are not body fields (id, party_id, revoked, active, created_at, updated_at) are ignored, a gated field sent with the value served is accepted, and end_date sent as served (the same instant in any offset, or the stored time's US Central date) is not written, so the stored time never moves. A different date, or a timestamp of a different instant, is stored as the start of its US Central day. When nothing changes the override is not saved: 200 with the entity, no recompute, no event, no email. One exception: an override with no factor_type and a coverage_prefix (or a signing_template_id), sent back as read, has its implied factor (insurance, or document_signing) written, as on any update that sends no factor_type (see above). That only makes the stored scope explicit; it never widens the override.

POST /approval_overrides/:id/revoke

Revokes the override and recomputes compliance, which can make the party non-compliant and start a new request (with its initial email). Event: Override Revoked. Response 200 with the entity.