Skip to main content
Version: Beta

Replace Extraction Rule

Replaces the extraction rule identified by id with the rule in the request body. Every editable field is overwritten; fields that are unset in the request are cleared on the stored rule. Use this when you have the entire desired rule state — for partial field updates, use the PATCH UpdateExtractionRule endpoint instead. Supports optimistic concurrency via the etag field — if the provided etag does not match the current version, the request returns HTTP 409 Conflict. The rule's archived state is preserved across the replace; use the archive/unarchive endpoints to change it.

Responses

200

A successful response.

Whole-resource replace. This PUT endpoint overwrites every editable field of the rule with the values in the request body. Fields that are unset on the request are cleared on the stored rule. Use this when you have the entire desired rule state — for example, after editing a rule in your own UI and re-saving it.

Round-tripping a Get response is supported. The natural workflow is Get → mutate → PUT. The PUT endpoint accepts every field returned by Get/List without requiring you to strip it first:

  • created_at, updated_at, etag (on the rule body), and archived are server-managed and silently ignored on input. Server-managed fields will be regenerated on save; archive state is preserved from the stored rule.
  • id on the rule body is allowed but, if set, must equal the id in the URL path. The path is the authoritative identifier; a mismatch is rejected as a likely client bug rather than silently overwriting the wrong rule.

Optimistic concurrency. As with the PATCH variant, pass the etag from the most recent Get or List response on the request itself (not just on the body). The server returns HTTP 409 Conflict if the rule has changed since you read it — re-fetch, reconcile, and retry.

Archived state is preserved. Replacing a rule does not change its archive status. Use the archive and unarchive endpoints to change it.