Skip to main content

Delete Data Product

Permanently delete a data product record via the API. The source runs, documents, and extracted data stay intact, so you can safely clean up test outputs.

Permanently delete a data product record. This is a hard delete of the product itself — the wrapper that groups runs, thresholds, and share configuration — and it is irreversible. The source runs, their documents, and all extracted data are untouched, because a product assembles run results on read rather than copying them.

Deleting via the API differs from archiving in the platform UI. Archiving is a soft delete that sets status: "archived" and keeps the product addressable; this endpoint removes the product row entirely, so its ID stops resolving and its share link, if any, goes dead. Prefer archiving when you might need the product again; delete when cleaning up test artifacts or decommissioning a deliverable for good.

Before deleting, check what still points at the product. Delivery bindings that reference it will start failing rather than being cleaned up automatically, and a published governed read contract does not survive the product it governs — any App or cross-pipeline rule consuming the product through its contract loses its source. The API does not block the delete on these references; auditing consumers first is your responsibility.

A sensible decommissioning order: revoke the share link (DELETE /share) so the public URL dies deliberately rather than as a side effect, deactivate or retarget delivery bindings, take a final CSV export if the dataset must be retained, and only then delete the product. Each step is independently reversible except the final delete.

Deletion is permanent and immediate. Any public share link for this product stops resolving, and delivery bindings that reference it will fail on their next attempt. Recreate an equivalent product from the same run IDs if you delete by mistake — the underlying run data survives.
DELETE/v1/data-products/{id}

Path parameters

id*uuidData product UUID.

Response

Response fields

deletedbooleanAlways true on success.
idstringUUID of the deleted product, echoed back for logging.

curl

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

Response

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

Errors

Error responses

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

Response (404 — already deleted or foreign ID)

{
  "statusCode": 404,
  "code": "RESOURCE_NOT_FOUND",
  "error": "Not Found",
  "message": "Data product 'd1a2b3c4-e5f6-7890-abcd-ef1234567890' not found.",
  "retryable": false
}

The delete is not idempotent at the HTTP level: repeating the call for an already-deleted product returns 404, the same response a foreign or mistyped UUID gets. Treat a 404 on delete as "already gone" in cleanup scripts rather than as a failure — the end state is identical.

Frequently asked questions

Does deleting a data product affect the source runs?+
No. The source job or resolution runs, their documents, and all extracted data are completely unaffected. Only the product record — the wrapper grouping those runs into a deliverable — is removed.
What happens to delivery bindings when a product is deleted?+
Bindings that reference the deleted product stop delivering data. The bindings themselves are not deleted, but they will produce errors on the next delivery attempt. Update or remove affected bindings after deleting a product.
Can I recover a deleted data product?+
No. The API delete is a hard delete of the product record. Because the source runs keep their results, you can recreate an equivalent product by calling `POST /v1/data-products` with the same `run_ids` — but its share link and generated IDs start fresh.
How is deleting different from archiving?+
Archiving (done from the platform UI) sets `status: "archived"` and keeps the product addressable and listable. The API DELETE removes the row entirely: the ID stops resolving and any public share link goes dead immediately.
Is repeating the delete call safe?+
Yes, but the second call returns 404 rather than a success body — the row is already gone, and a missing product is indistinguishable from one that never existed. Cleanup scripts should treat a 404 on delete as success.

Related

List Data Products
Create Run-Backed Data Product
Resolutions
Schemas