Skip to main content

Delete Data Policy

Permanently delete a data policy and cascade its versions, fields, and rules. Resolution runs keep captured snapshots for audit. Irreversible; write scope.

Permanently delete a data policy and everything under it: versions, fields, and rules. This action is irreversible. Resolution runs that previously captured a snapshot of the policy are not affected, because each run retains its own copy of the configuration it executed.

Deleting is the right call for abandoned drafts and superseded experiments; for a policy that ever ran in production, consider keeping it instead — the policy row costs nothing, and keeping it preserves the ability to inspect the exact fields and rules behind historical output without digging through run snapshots. A rename via PATCH (for example, prefixing "DEPRECATED —") is often the better retirement mechanism.

Deletion is permanent. All versions, fields, and rules of this policy are removed, and future pipelines can no longer reference it. Existing resolution runs with captured snapshots keep working and stay auditable.

Deletion cascades through the policy's full tree: every version, and each version's fields and rules, are removed with the policy row. There is no soft-delete or trash — a deleted UUID immediately returns 404 on every read, and a second DELETE of the same id also returns 404 not_found rather than a repeated success, which makes the call safe to retry while still surfacing when something else already removed the policy. The endpoint requires an API key with the write scope; a read-only key receives 403 before any lookup happens.

DELETE/v1/data-policies/{id}

Path parameters

id*uuidData policy UUID.

Response

Response fields

deletedbooleanAlways true on success.
idstringUUID of the deleted policy.

curl

curl -s -X DELETE https://api.talonic.com/v1/data-policies/p1a2b3c4-e5f6-7890-abcd-ef1234567890 \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

{
  "deleted": true,
  "id": "p1a2b3c4-e5f6-7890-abcd-ef1234567890"
}

Errors

Error responses

401unauthorizedMissing or invalid API key.
404not_foundData policy not found or does not belong to your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Before deleting, export the configuration you might want back: GET /v1/data-policies/{id} returns the full policy with fields and rules inlined, which is enough to reconstruct it later. If the policy is wired into a pipeline's Resolve stage, update the pipeline first so future runs do not reference a missing policy.

Tenant scoping applies as everywhere on this API: the delete matches only policies owned by your organization, so a valid UUID belonging to another tenant is indistinguishable from a missing one — both return 404 not_found. Cleanup automation can therefore treat 404 as "already gone" without leaking whether the id ever existed, and without needing a pre-flight read.

Frequently asked questions

Does deleting a policy break existing resolution runs?+
No. Resolution runs capture a complete policy snapshot at creation time. Deleting the policy only prevents future resolution runs from using it. All historical results are preserved.
Can I recover a deleted policy?+
No. Deletion is permanent. If you need to preserve a policy configuration, export it via the GET endpoint before deleting. You can inspect historical snapshots in completed resolution runs.
What happens to pipelines that reference the deleted policy?+
Completed runs keep their snapshots and remain auditable. Update any pipeline that still references the policy in its Resolve stage before deleting, so new runs do not point at a missing policy.
Is deleting a policy idempotent?+
Effectively: the first call deletes and returns `{"deleted": true}`; any repeat returns `404` because the row is gone. Treat `404` as "already deleted" in cleanup scripts. There is no undo — exporting via GET /v1/data-policies/{id} beforehand is the only recovery path.
Should I delete or just stop using a retired policy?+
Delete abandoned drafts freely. For a policy that ran in production, keeping it (optionally renamed with a DEPRECATED prefix via PATCH) preserves the readable record of the fields and rules behind historical output; deletion leaves only the per-run snapshots as evidence.

Related

List Data Policies
Get Data Policy
Resolutions