Skip to main content
See Knowledge Patches capability for why the agent proposes instead of writing.

GET

pendingCount is always the account-wide total regardless of the filter, so a nav badge stays correct whichever tab you’re on.

Field meanings

  • targetTypecompany_profile, app_profile, or document.
  • targetField — the profile field (icp, doNotTouch). Null for documents.
  • targetPath / targetSection — for documents: the file and the heading inside it, so applying is surgery on that section rather than a rewrite.
  • operationreplace or append. An append adds a line and can’t destroy an edit, so it skips the conflict check.
  • originrun · chat · drift_audit · fact_promotion · document_extraction.
  • currentValue — captured when the patch was written, so a review UI has a left-hand side. Compare it against the live value before applying blind.

POST /:id/apply

Applying sets the row’s source to user — you decided, so it’s yours. Document patches record a revision under your name.

409 — the target moved

Nothing was written and the patch stays pending. Show currentValue, then either drop it or retry with force: true.

POST /:id/reject

{"rejected": true}. Returns 400 if the patch doesn’t exist or was already reviewed. Rejected patches don’t come back with the same fingerprint.

Use cases

  • A review inbox in your own dashboard, mirroring Settings → Business.
  • Auto-apply high confidence — e.g. apply fact_promotion patches above 0.9 unattended, queue everything else. Consider this carefully for constraints and doNotTouch: those become blocking rules.
  • Audit what changed your context by listing status=applied and diffing currentValue against appliedValue.
  • Company API — the fields patches target, plus POST /company/extract which queues them
  • Documents API — document patches land here