A REST request that creates, changes, or deletes data does not request a Time Layer copy. Catalog also does not request one separately when it applies an attribute-definition change. Treat the request as unprotected unless you have checked a suitable copy yourself. This applies even when the change is initiated through the Catalog attribute-management REST routes.
The Catalog SPA may offer a copy before a risky change and request it directly from Time Layer. That internal flow is not available to REST integrators. REST endpoints for managing Time Layer copies are a future proposal, not a current API capability.
- Identify the account and the change you intend to make. Read the current attribute definition and review the affected items or values before preparing a
PATCHorDELETE. See Entity metadata and attribute management for the read routes. - In Sales Layer Cloud, open Activity and its recent activity view. If your account offers the action to generate a backup (labelled “Generar copia de seguridad” in the Spanish interface), use it before sending the REST request. The action appears only when Time Layer is active and included for the account, the user can view recent activity, the account has activity visible within the past year, and the Activity view offers a copy at that point. Availability depends on the account and what the screen displays.
- Wait for Cloud to finish, then find a new Time Layer entry in the activity feed and check its date and time. Copies appear among activity entries, within the date range shown on the current page. Confirm that the entry represents a copy made before your planned REST change. A green message saying a copy was not necessary does not mean a new copy was created. A success message alone is not enough: verify the entry.
- Send the REST request only after you have confirmed the copy you intend to rely on. Record its date and time alongside your change record so that you can identify it later.
Do not rely on a scheduled, session-triggered, or operation-triggered Cloud copy as proof that your REST request is protected. Such copies may not be created, and a Cloud operation can continue when its attempted copy fails. Verify a suitable copy in Activity before proceeding.
If the backup action is unavailable, Cloud reports that no new copy was needed, or you cannot find and verify a suitable copy, pause the risky REST change. Ask Sales Layer Support or your account contact to help confirm your account's Time Layer availability and the copy you can use. Do not assume that the REST API provides another way to create or check a copy.
The following effects are defined by the current Catalog endpoint reference for the four attribute route families: Categories, Products, Variants, and Custom Entities. The copy rule above applies to all of them.
| REST change | Documented effect |
|---|---|
PATCH .../attributes('{attributeId}') with a new type | Converts an attribute. Values that the destination type cannot carry are emptied. Only the tenant's own attributes can be converted. |
PATCH .../attributes('{attributeId}') with deleteExistingValues: true | Empties that attribute's value on every item, whatever else the request changes. Omitting the field does not request that clearing; a type conversion may still empty values it cannot carry. |
PATCH .../attributes('{attributeId}') with checklist options | A supplied list replaces the whole option list. An omitted option stops being offered; items tagged with it keep the text they carry. An empty list is rejected. |
DELETE .../attributes('{attributeId}') | Deletes a tenant-owned attribute definition and its item values. Platform attributes cannot be deleted. |
Product or Variant DELETE with onlyFromForm=true | Removes the attribute only from the default form, or from the form selected by attributeSetId. The definition and item values remain. Categories and Custom Entities do not support this form-only mode. |
For example, a Product attribute deletion without onlyFromForm=true removes its values from every Product. Before sending that request, check the definition and affected data, then complete the Cloud copy check above. For a checklist update, compare the full proposed options list with the existing list; removing an option from the definition does not remove the text already held by tagged items. For deleteExistingValues: true, expect all values of that attribute to be emptied.
The OpenAPI DELETE descriptions say that no snapshot is taken before the request. This describes the REST operation; it does not prevent you from creating a separate copy in Cloud first.
Time Layer copies may not remain available indefinitely. Check that the copy you intend to rely on is available in Cloud when you need it.
Restoring a copy affects the account's catalog, rather than a single attribute. It may replace catalog changes made after the copy. If your integration depends on creating, retaining, or restoring Time Layer copies, consult your Sales Layer contact or Customer Success for information about your account before planning the workflow.