Trash

Many records on revenexx do not disappear when you delete them. They go to the trash first, where they stop acting and drop out of the lists, but they can still come back. This page describes the rules that the record families share. Each family page names its own refusals and any extra rules, and links back here.

As of 2026-11, 20 record families use the trash. Twelve of them also have a purge route (see Empty or purge).

The shared operations

Each family has the same routes. <family path> is the family's base path, such as /v1/loyalty/programs.

Delete for good means the record is removed and cannot come back. A second DELETE, emptying the trash, the purge and the daily purge all do it.

A purge or an empty can leave some records behind. A record that something still holds stays in the trash, and the answer says why.

Listing the trash

The list call takes a trashed query parameter:

• Left out, or exclude: trashed records are not in the answer. exclude is not a value on the four product families (products, product assets, categories and manufacturers), where leaving the parameter out gives the live records only.
• only: the trash alone.
• include: the live records and the trashed records together.

curl "https://api.revenexx.com/v1/loyalty/programs?trashed=only" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>" \
  -H "X-Revenexx-Api-Key: rvxk_..."

The calls above need a tenant slug and an API key. The authentication page explains the X-Revenexx-Tenant and X-Revenexx-Api-Key headers and how to get both.

The trash fields

All 20 families carry the same six trash fields, as the API spec shows, as of 2026-11.

Restore

POST <family path>/{id}/restore takes a record out of the trash and clears its trash marks. On most families nothing else on the record changed when it went to the trash, so it comes back as it was, and everything that pointed at it acts again. The family page names any exception: a contact's login is switched off when it goes to the trash and back on at the restore, for example.

• Batch restore is the shared rule. A restore brings back every record that carries the same trash_batch, which is every record that went to the trash in the same delete. A delete can take children along: the variants of a product model, or the subtree of a category, for products and categories, and the contacts of an organization. A record that was trashed on its own earlier keeps its own batch and stays in the trash.
• Restoring needs the same right as deleting.
• A refused restore answers 409. The shared code is not_in_trash, for a record that is not in the trash. The family pages name the other reasons. An id that no record of your tenant has answers 404.

Empty or purge

These two calls look alike but do different things.

Empty (trash/empty) is for all 20 families. It deletes every record in the trash for good, now. Each record gets the same checks as a second DELETE. A held record stays in the trash and is named in the answer with its reason. The rest still go.

• Per call: the limit on one empty call is in the table below.
• more is in the answer on seven families: products, product assets, categories, manufacturers, contacts, organizations and segments. When more is true, call the route again. The other 13 families answer with deleted and blocked and no more; call again until deleted comes back empty.
• A storefront contact gets 403 on trash/empty for all 20 families. Emptying the trash is back-office work.
• Delete for good cannot be undone.

Purge (trash/purge) is for the 12 families with a purge route. It deletes for good only the records that have been in the trash longer than the tenant's retention. The platform runs the same job every day. The call runs it by hand, under the same rules as emptying the trash, and a held record stays with its reason. If the retention cannot be read, nothing is deleted.

The daily purge also covers the other eight families, customers included. Once a trashed record is past the retention and nothing holds it, the daily purge deletes it for good. These eight families have no purge route to call by hand.

Retention

The retention is trash_retention_days, from GET /v1/audit/settings. The default is 90 days, unless your tenant set another value. See Audit for how to read it.

Events

• On the families the event catalog lists (below), the first delete fires <record>.trashed and a restore fires <record>.restored.
• <record>.deleted fires only when a record is deleted for good.
• The payloads carry trash_batch. The product, category, manufacturer and asset payloads also carry root_id, the record the call was made on. The promotion and customer payloads carry group, the ids that went with a delete. Restore payloads carry restored_at; the customer ones also carry restored, the ids that came back.

The event catalog lists trash events only for those nine families, as of 2026-10: products, categories, manufacturers, assets, price lists, promotions, organizations, contacts and segments.

The families