# Recurring Orders overview

Overview of the concepts related to Recurring Orders and the checkout process.

A [Recurring Order](/api/projects/recurring-orders.md) defines the schedule and configuration for automatically creating and placing future Orders at regular, predefined intervals on behalf of a customer. It acts as the base for generating new Orders according to the specified recurrence schedule.

Learn more about using Recurring Orders for B2B replenishment in our self-paced [Implement B2B purchase flows](/learning-model-b2b-commerce/implement-b2b-purchase-flows/recurring-orders-for-b2b.md) module.

## General concepts

### Recurrence Policies

A [Recurrence Policy](/api/projects/recurrence-policies.md) lets you define a schedule for selling recurring products at specific prices. The recurring order can occur on a specific day of every month, or at fixed intervals. You define Recurrence Policies on individual Line Items and Custom Line Items as well as individual prices (both Standalone and Embedded).

A Project can have multiple Recurrence Policies at the same time and they can be reused across different Recurring Orders.

You have two options for choosing a schedule:

- [StandardSchedule](/search.md?urn=ctp:api:type:StandardSchedule): daily, weekly, or monthly
- [DayOfMonthSchedule](/search.md?urn=ctp:api:type:DayOfMonthSchedule): a specific date of each month

#### Standard schedules

Within each standard schedule, you define the `intervalUnit`, for example `Days`, `Weeks`, or `Months`, and also the `value` field, which represents the number of intervals between orders.

| Order frequency | Value | Interval unit |
| --- | --- | --- |
| Daily | `1` | `Days` |
| Weekly | `1` | `Weeks` |
| Monthly | `1` | `Months` |
| Every 10 days | `10` | `Days` |
| Every 2 weeks | `2` | `Weeks` |
| Every 3 months | `3` | `Months` |

#### Day Of Month schedules

To schedule a Recurring Order on a specific day of the month, you can use the [DayOfMonthSchedule](/search.md?urn=ctp:api:type:DayOfMonthSchedule).

### Recurring items

[Line Items](/api/projects/carts.md#lineitem) and [Custom Line Items](/api/projects/carts.md#customlineitem) carry information about possible recurrence. For each recurring item, you define when or how often the item should be ordered, as well as the pricing mode using a Recurrence Policy.

#### Define a schedule or interval

To set the schedule or interval:

- Create (or add) a Line Item or Custom Line Item with the `RecurrenceInfo` field set:
  - For [Line Items](/api/projects/carts.md#lineitemrecurrenceinfodraft)
  - For [Custom Line Items](/api/projects/carts.md#customlineitemrecurrenceinfodraft)

- Update a Line Item or Custom Line Item with the `RecurrenceInfo` field set:
  - For [Line Items](/api/projects/carts.md#set-lineitemrecurrenceinfo)
  - For [Custom Line Items](/api/projects/carts.md#set-customlineitemrecurrenceinfo)

#### Define a price selection mode

A Recurring Order can span several months, resulting in the generation of multiple scheduled orders over time. When selling a product over an extended period, it's common for its price to change—sometimes more than once.

To define how price updates affect existing Recurring Orders, you define the [PriceSelectionMode](/search.md?urn=ctp:api:type:PriceSelectionMode) through the `recurrenceInfo` field on each recurring item. The price selection mode determines whether Recurring Orders should retain the original item price or adopt the new price going forward.

You can choose one of the following price selection modes:

- `Fixed`: the price set at the time the Recurring Order was created remains the same. With this configuration, any changes made to the Product's price **will not affect** existing Recurring Orders.
- `Dynamic`: each time a new order is generated from a Recurring Order, the platform retrieves and applies the current Product price. With this configuration, any updates to a Product's price **will affect** all existing Recurring Orders going forward.

```mermaid
flowchart
 LineItem --> P[Price Selection Mode]
 P --> Fixed
 Fixed --> N[No Changes]
 P --> D[Dynamic]
 D --> DB[(Find Latest Price)]

```

### Prices

Prices (both Embedded and Standalone) carry information about possible recurrence. Each price that is defined on a recurring item must be connected to a Recurrence Policy.

When selecting a price for a Recurring Order, the platform will use the standard price selection rules, along with the specified Recurrence Policy, to determine the correct price for the given SKU and recurrence. If no such price is found, the platform defaults to using the standard one-time purchase price.

For example, for a Recurring Order using an SKU with a `monthly` recurrence, the platform will attempt to locate a price explicitly tied to that `monthly` policy.

You only need to set recurrence information on prices if you intend to offer special pricing for recurring items; otherwise, no changes to your existing pricing configuration are needed.

```mermaid
 flowchart
 A[Product] --> B[SKU]
 B[SKU] --> C[(Find Price)]
 C --> D(Embedded Price with Recurrence Policy)
 C --> E(Standalone Price with Recurrence Policy)
 D --> F{Found Price?}
 E --> F
 F --> |Yes| G[Use specific price]
 F --> |No| H(Use one-time Price)


	 style G fill:#eeeee4
	 style H fill:#eeeee4
```

For example, to sell yogurt in 3 different intervals, you set a price for each interval:

```mermaid
 graph LR
	 A[Yogurt]--> B($1)
	 B --> C(Once a Week)
	 A --> D($1.5)
	 D --> E(Every 2 Weeks)
	 A --> G($2)
	 G --> H(Once a Month)

	 style A fill:#eeeee4
```

If you are using Standalone Prices, create a new price via the [Create StandalonePrice](/search.md?urn=ctp:api:endpoint:/{projectKey}/standalone-prices:POST) endpoint, and set the desired [Recurrence Policy](/api/projects/recurrence-policies.md#recurrencepolicy) in the [StandalonePriceDraft](/search.md?urn=ctp:api:type:StandalonePriceDraft) object.

If you are using Embedded Prices, add a new price via the [Add Price](/api/projects/products.md#add-price) update action, and set the desired [Recurrence Policy](/api/projects/recurrence-policies.md#recurrencepolicy) in the [PriceDraft](/api/types.md#pricedraft) object.

If you are using external pricing, you can set the price for the individual Line Item or Custom Line Item on the Cart, when creating or updating the Cart.

### Recurring Carts

A [Cart](/search.md?urn=ctp:api:type:Cart) with the [CartOrigin](/search.md?urn=ctp:api:type:CartOrigin) `RecurringOrder` is known as a recurring Cart and is used as the source to create all subsequent orders generated by a specific Recurring Order. A recurring Cart contains only Line Items and Custom Line Items that are linked to a [Recurrence Policy](/api/projects/recurrence-policies.md#recurrencepolicy).

Recurring Carts are not deleted by the [automatic cleanup](/api/general-concepts.md#automatic-cleanup), even if no changes occur within a 90-day period.

To learn how recurring Carts are created, see [Initial creation](/api/recurring-orders-overview.md#initial-creation).

## Recurring Orders

### Initial creation

To create a Recurring Order, you can use the following methods:

| Method | Description | Use case |
| --- | --- | --- |
| [Create Order from Cart](/search.md?urn=ctp:api:endpoint:/{projectKey}/orders:POST) (Orders API) | Automatically checks Line Items and Custom Line Items for recurrence information, and if found, creates a Recurring Order for each recurrence schedule that is found. | Use when the Cart contains a mix of one-time and recurring purchases, or recurring items with different schedules. |
| [Create RecurringOrder](/search.md?urn=ctp:api:endpoint:/{projectKey}/recurring-orders:POST) (RecurringOrders API) | Requires a Cart where all Line Items and Custom Line Items are recurring and share the same recurrence schedule. You can also set the `startsAt`, `expiresAt`, `custom` fields. | Use when all items in the Cart are linked to a recurrence schedule and/or you need flexibility to define when the Recurring Order starts, stops, and to store custom information. |

#### Method A: Create Order from Cart

The following steps describe the process when using the [Create Order from Cart](/search.md?urn=ctp:api:endpoint:/{projectKey}/orders:POST) endpoint on the Orders API:

1. On the [OrderFromCartDraft](/search.md?urn=ctp:api:type:OrderFromCartDraft), you specify the `cart` that contains items.
2. An Order is created from the specified Cart.
3. The platform evaluates the Line Items and Custom Line Items:
   1. If no recurrence information is found, no further action is taken.
   2. If one or more items contain recurrence information:
      - Recurring items are grouped by their recurrence schedule (specified in the [Recurrence Policies](/api/recurring-orders-overview.md#recurrence-policies)).
      - For each group, a new Recurring Order **and** a new recurring Cart are created.
      - Each recurring Cart inherits the base configuration of the original Cart (for example, tax mode, customer group, inventory mode, store, business unit) but contains only the items that belong to that group.
      - If multiple shipping methods are used, only the shipping methods and addresses associated with the items in the group are copied to the new Cart.

#### Method B: Create RecurringOrder

The following steps describe the process when using the [Create RecurringOrder](/search.md?urn=ctp:api:endpoint:/{projectKey}/recurring-orders:POST) endpoint on the Recurring Orders API:

1. On the [RecurringOrderDraft](/search.md?urn=ctp:api:type:RecurringOrderDraft), you specify the `cart` that contains the recurring items.
2. A new Recurring Order is created.
3. The `origin` field on the specified Cart changes to `RecurringOrder`.

### Subsequent Orders

Once a Recurring Order is created, the platform automatically creates new Orders based on the defined schedule. Each Recurring Order contains the following information:

- `cart`: the recurring Cart for this Recurring Order. It serves as a blueprint for generating future orders.
- `nextOrderAt`: the date and time when the next order will be created.
- `originOrder`: the original Order from which this Recurring Order was initiated. This field is only populated when the Recurring Order is created via the [Create Order from Cart](/search.md?urn=ctp:api:endpoint:/{projectKey}/orders:POST) endpoint.
- `startsAt`: date and time when this Recurring Order becomes active and eligible to generate new Orders.
- `schedule`: The defined interval that determines how often new orders are generated for this Recurring Order.

Delays can occur due to application or server-side processing.

The following example shows when the next orders are created for a Recurring Order configured with a weekly interval.

| Date | Status | Order created | nextOrderAt |
| --- | --- | --- | --- |
| 1 Jul 2025 | Active | ✓ | 8 Jul 2025 |
| 8 Jul 2025 | Active | ✓ | 15 Jul 2025 |
| 15 Jul 2025 | Active | ✓ | 22 Jul 2025 |
| 22 Jul 2025 | Active | ✓ | 29 Jul 2025 |
| 29 Jul 2025 | ... | ... | ... |

### Paused Orders

You can pause a Recurring Order at any time. When paused, subsequent Orders will not be created until the Recurring Order is reactivated.

The following example shows when the next orders are created for a Recurring Order configured with a weekly interval that has been paused and then reactivated.

| Date | Status | Order Created | nextOrderAt |
| --- | --- | --- | --- |
| 1 Jul 2025 | Active | ✓ | 8 Jul 2025 |
| 6 Jul 2025 | Paused by the user | ✗ | `empty` |
| 19 Jul 2025 | Reactivated by the user | ✗ | 22 Jul 2025 |
| 22 Jul 2025 | Active | ✓ | 29 Jul 2025 |
| 29 Jul 2025 | Active | ... | ... |

## Example

A customer wants to buy 4 different products (SKUs). Their Cart has the following items:

| Item | Purchase interval | Ship to |
| --- | --- | --- |
| SKU1 | One-time purchase | Home |
| SKU2 | Weekly | Home |
| SKU3 | Monthly | Office |
| SKU4 | Monthly | Office |

The customer completes the checkout process and receives an email with the confirmation.

Internally, the following steps happen:

- A new Order is created with all four items.
- The platform determines that three of the four items are recurring and groups them by their recurrence interval:
  - **Group A**: SKU2 (weekly)
  - **Group B**: SKU3 and SKU4 (monthly)
- For each group, a new Recurring Order and a new recurring Cart are created.
- The new recurring Carts inherit the base configuration of the original Order.

This results in the following:

- **Recurring Order A**: SKU2 is shipped weekly to the home address.
- **Recurring Order B**: SKU3 and SKU4 are shipped monthly to the office address.

Each Recurring Order holds a link to the [recurring Cart](/api/recurring-orders-overview.md#recurring-carts) that contains the items which share the same schedule.

Every new Order will execute all related [API Extensions](/api/projects/api-extensions.md), and generate the [OrderCreatedFromRecurringOrder](/api/projects/messages/cart-order-messages.md#order-created-from-recurring-order) Message. Orders generated by a Recurring Order schedule do not emit the standard [OrderCreated](/api/projects/messages/cart-order-messages.md#order-created) Message; the `OrderCreated` Message is emitted only for the initial Order created directly from a Cart.

## Handle errors

Errors prevent subsequent Orders from being created and cause the Recurring Order's [state](/api/projects/recurring-orders.md#recurringorderstate) to change to `Failed`.

To reactivate the Recurring Order, you must first resolve the issue. Once corrected, you can change the state to `Active` using the [Set RecurringOrder State](/api/projects/recurring-orders.md#set-recurringorderstate) update action.

## Further resources

For a complete walkthrough on how to setup and create a Recurring Order, see our [Create a Recurring Order](/tutorials/create-a-recurring-order.md) tutorial.

## Related pages

- [Area overview page with navigation](/api.md)
- [Next page: Recurrence Policies](/api/projects/recurrence-policies.md)
- [Search documentation and API specs](/search.md)