> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metricanic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Archive and restore entities

> Retire tracking entities without erasing them, resolve dependency conflicts, and restore campaigns in a publishable state.

Archiving removes an entity from active use while retaining its record. Use it when retiring a campaign or cleaning up reusable assets that you may need again. The public entity `DELETE` operations perform soft archive, and the bulk `/restore` operations reactivate records.

An archive is an operational change. Archiving a campaign queues removal of its tracking configuration from service. It is not a way to pause the advertising campaign at your traffic source.

## Follow the dependencies

The tracker prevents you from archiving reusable assets that are still needed by other entities.

| Entity            | What can block archive                |
| ----------------- | ------------------------------------- |
| Traffic source    | A non-archived campaign references it |
| Rotator           | A non-archived campaign references it |
| Offer             | A rotator offer pool references it    |
| Landing           | A rotator landing pool references it  |
| Affiliate network | A non-archived offer references it    |

For example, retiring one offer starts with the rotators that use it. Replace or remove the offer from those pools, verify the remaining routes, and then archive the offer. Archiving a campaign does not automatically remove an offer's membership in a rotator pool.

When retiring an entire funnel, work from consumers toward shared dependencies. Archive the campaigns that should stop, then retire their rotators and assets only after checking whether other campaigns still use them.

## Archive a selected batch

Bulk archive and restore routes accept an `ids` array with 1 to 200 entries. Use the resource-specific endpoint, for example:

```bash theme={null}
curl --request POST 'https://panel.metricanic.com/api/v1/campaigns/archive' \
  -H "Authorization: Bearer $METRICANIC_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"ids":["CAMPAIGN_ID"]}'
```

This requires a **write** key. On success, the response contains `data.archived`. The handler checks that all requested IDs exist in the workspace before applying the batch. Dependency conflicts return `409` with details where available, rather than silently ignoring blocked items.

Campaign unpublication is queued. A successful archive response confirms that the archive was accepted, not that every tracking location has finished updating at that exact moment. Stop paid traffic at its source when retiring the campaign, then verify the tracking change.

## Restore the route before restoring traffic

Use the matching restore endpoint:

```bash theme={null}
curl --request POST 'https://panel.metricanic.com/api/v1/campaigns/restore' \
  -H "Authorization: Bearer $METRICANIC_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"ids":["CAMPAIGN_ID"]}'
```

A campaign restore requires a rotator with a publishable default stream. Restore or repair the assets and rotator first, then restore the campaign. The campaign restore response includes `runtimePendingIds` and `runtimePublishedIds`, so inspect those fields instead of treating `restored` as proof of completed publication.

For example, if a campaign restore returns `campaign rotator has no publishable default stream`, inspect its default rotator path and its active destinations. Repeating the campaign restore cannot make a missing destination publishable.

Restoring a rotator reactivates its record. Restoring an offer or landing can queue related rotator recompilation. These operations do not automatically resume advertising outside Metricanic.

## Verify before resuming

Read the restored entity and confirm its status and relationships. Check the campaign's tracking configuration and complete a controlled visit through the intended route before resuming traffic.

Entity list behavior is endpoint-specific. Use `includeArchived=1` where the endpoint supports it when looking for retired records, and use the documented response fields to obtain their IDs. Do not treat disappearance from a default active list as permanent deletion.

If restoration fails, use the returned `missing`, `blocked`, or `blockedCampaignIds` details to identify what needs attention, then follow [API errors](/api-reference/errors) for the appropriate next step.