Update Extraction Rule

PATCH merges only requested fields — omit a field to leave it unchanged. Supported optional fields: name, description, source, and mappings. When mappings is provided, it replaces the entire mappings list for the rule (there is no patch-by-entry). When source is provided, it replaces the rule source. Concurrent writes follow last-write-wins semantics: the most recent successful update is preserved.

Beta: This API is in beta, functionality and documentation are subject to breaking change without notification. If you'd like to share feedback please click here.

Responses

200

A successful response.

Patchable fields. Send any subset of name, description, source, and mappings. The other rule fields are not patch-eligible: id, created_at, updated_at, and archived are server-managed (use the archive/unarchive endpoints to change archive state); scope is immutable on PATCH — to change scope, archive the rule and create a new one with the desired scope.

Whole-field replacement for source and mappings. When mappings is set, the entire mappings list is replaced — sending one mapping does not append, it overwrites. When source is set, the entire source is replaced. To edit inside those structures, Get the current rule, mutate the field locally, then send the whole rule back via PUT (or send the updated source / mappings value back via PATCH).

Clearing description. Omit description to leave it unchanged; send "description": "" to clear it.

Concurrency. Concurrent updates follow last-write-wins: if two clients update the same rule at the same time, the most recent successful write is preserved. The legacy etag field is still accepted on the request and returned on responses for backward compatibility, but the server no longer validates or honors it.

PATCH vs PUT. Use this PATCH endpoint to change a few fields and leave the rest as-is. Use the sibling PUT /v2beta/extraction/rules/{id} (Replace Extraction Rule) when you have the full rule and want to overwrite every editable field.