> This page is for version v2 (default).
> For other versions, use one of these documentation indexes:
> - v2 (default): https://docs.paid.ai/v-2/llms.txt
> - v1: https://docs.paid.ai/v-1/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.paid.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.paid.ai/_mcp/server.

# Product lifecycle and archival semantics

> Understand how product archival affects listings, checkout flows, billing, usage attribution, and existing customer relationships.

Products in Paid follow a soft-archival lifecycle. Archiving a product hides it from places where you would set up something new, such as product pickers, listings, and onboarding flows, but it does **not** invalidate existing references to that product. Customers who already have an order or subscription for an archived product continue to bill normally.

## What archiving a product means

Archiving sets `archivedAt` on the product. The intent is "this product is no longer offered to new customers". It is **not** a soft delete, and it is **not** a signal that existing customer relationships should stop.

## Behavior after archive

### Continues to work

* **Order creation against archived products is accepted.** `POST /v2/orders` does not reject orders that reference an archived product. This protects integrations that hardcode product IDs.
* **Existing orders bill as normal.** The billing engine resolves usage and credits through `OrderLine.productId`, which keeps pointing at the archived product. Order amendments and upgrades on those lines also continue to work.
* **Usage signals attribute correctly.** Signals sent against an archived product, via `POST /v2/signals`, OTLP, or other ingest paths, continue to resolve to the customer's existing order line and deduct credits or accrue usage as expected.
* **Cost ingest accepts records for archived products.** `POST /v2/cost` accepts cost records that reference an archived product so that in-flight integrations keep working.
* **Checkout upgrade flows** for customers already on a plan tied to the archived product continue to function.

### Is prevented

* **Listing and pickers hide archived products.** `GET /v2/products` excludes archived products from the default listing. Frontend pickers, including onboarding pricing, checkout link creation, and the HubSpot product picker, hide them.
* **New promotions cannot target an archived product.** Promotion scope must reference an active product at the time the promotion is created or edited.
* **Copy-to-live is blocked** for archived source products.
* **Admin exports** exclude archived products by default.
* **HubSpot CRM sync** does not surface archived products to new HubSpot views.

### Is a no-op

Existing promotions that already reference a product are not retroactively invalidated when that product is archived. They continue to apply to in-flight customers.

## Unarchiving

Setting `archivedAt` back to `null` restores the product to active state. Existing customer relationships were never disturbed, so unarchiving is purely a UI and listing operation.

## Guidance for integrators

You can safely hardcode product IDs in your integration. If a product is archived on Paid's side:

* Order creation against the archived product still succeeds.
* Usage signals against the archived product continue to bill.
* Product pickers and listings, including the dashboard and checkout-link creation UI, will hide the archived product, so new checkout links and new orders set up through Paid's UI will use a successor product.