Skip to main content

Delete Package Config

Delete a matching package config by ID. The delete cascades to every run created from the config and is permanent, so export run history you need first.

Delete a matching package config by its UUID. The delete cascades: every package run created from this config is removed along with it. The config must belong to your organization, and this endpoint requires the write scope.

Because the cascade removes run history, deleting a config is destructive. If you need to keep the runs for audit, export them via the runs list endpoint before deleting — page through GET /v1/matching/packages/runs?package_config_id=<id> and persist the pages, since after the delete those runs are gone from the API. Deletion is permanent and cannot be undone.

The cascade is scoped to the package layer only. The per-type matching configs referenced by the slots, their reference datasets, and any single-document matching runs under /v1/matching are untouched — a package config is a thin orchestration layer, and deleting it never deletes the building blocks it points at. Other package configs referencing the same matching configs keep working.

The lookup is tenant-scoped. Attempting to delete a config that does not exist, or that belongs to another organization, returns 404 not_found. A successful delete returns { "deleted": true }. The call is not idempotent at the HTTP level: a retry of an already-successful delete gets a 404 because the config is gone — so in retry logic, treat a 404 on a delete you previously attempted as success rather than an error worth alerting on.

A deleted config id also invalidates future run triggers immediately: POST /v1/matching/packages/runs resolves package_config_id before executing, so any pipeline still pointing at the deleted id starts failing with 404 not_found on its next trigger. Repoint those callers to the replacement config before deleting, not after, if you are swapping configs in place.

Deleting a package config cascades to its runs. Export any run history you need to retain before calling this endpoint, because the delete is permanent.

Export run history first

# Page through the config's runs and save them before deleting
curl -s "https://api.talonic.com/v1/matching/packages/runs?package_config_id=4f2a9c1e-8b3d-47e6-9a05-c7d1e2f3a4b5&limit=100" \
  -H "Authorization: Bearer tlnc_your_api_key" > runs-page-1.json
# Repeat with ?cursor=<next_cursor> until has_more is false
DELETE/v1/matching/packages/configs/{id}

Path parameters

id*stringUUID of the package config to delete. Must belong to your organization.

curl

curl -X DELETE https://api.talonic.com/v1/matching/packages/configs/4f2a9c1e-8b3d-47e6-9a05-c7d1e2f3a4b5 \
  -H "Authorization: Bearer tlnc_your_api_key"

Response

Response fields

deletedbooleanTrue when the config and its runs were removed.

Response

{
  "deleted": true
}

Errors

Error responses

400validation_errorInvalid config ID format. Must be a UUID.
401unauthorizedMissing or invalid API key.
404not_foundNo package config with this ID exists for your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Frequently asked questions

Does deleting a config delete its runs?+
Yes. The delete cascades to every package run created from the config. Export any runs you need before deleting.
Can I undo a delete?+
No. Deletion is permanent. There is no soft-delete or recovery for package configs through the public API.
What scope does deleting a package config require?+
The write scope. API keys limited to the read scope can list and inspect configs but cannot delete them, which is a useful separation for reporting integrations.
Does the delete touch the underlying matching configs?+
No. The cascade removes only the package config and its package runs. The per-type matching configs, their reference data, and single-document runs under /v1/matching all survive, and other package configs referencing the same matching configs keep working.
What happens to integrations still triggering runs against the deleted config?+
Their next POST /v1/matching/packages/runs fails with 404 not_found, since the config id is resolved before execution. Swap callers over to the replacement config id first, then delete the old config once nothing references it.
Is the cascade atomic, or can runs outlive their config?+
Atomic. Package runs reference the config with a database-level ON DELETE CASCADE foreign key, so the config row and every run row disappear in the same operation — there is no window where orphaned runs remain readable, and no partial delete to clean up after a failure.

Related

Get Package Config
List Package Configs