Order subscriptions
The order subscription object and the allowed CRUD operations on the related resource endpoint
Last updated
The order subscription object and the allowed CRUD operations on the related resource endpoint
Last updated
Order subscriptions allow repeating a given source order according to a specified frequency: smaller is hourly, larger is yearly. If you need a custom frequency that is not in the list of allowed values, you can use a crontab expression.
Order subscriptions can be generated automatically from the line items that have a frequency using a trigger attribute at the order level (in this case recurring order copies are used as the order factory that generates the target orders) or manually (in this case the process usually leverages order copies). You can turn an existing manual order subscription into an automatic one by sending the _convert trigger attribute, provided that you previuosly defined a subscription model for the associated market.
To suspend or cancel an order subscription you can use the _deactivate and _cancel trigger attributes.
Currently, order subscriptions have no retry policy: in case, for any reason, the order copy fails, the errors_count counter is incremented, but the subscription is kept active (unless expired, deactivated or cancelled).
It is possible to check the succeeded_on_last_run attribute to inspect subscription last run state: if false, you can inspect the last associated recurring_order_copy or order_copy to fix any missing/bad data.
You can attach on order subscriptions, recurring order copies, and order copies events, to act promptly in case something unexpected happens. You can also set the renewal_alert_period attribute (expressed in hours — the minimum value is 1, the maximum value is 720 e.g. 30 days) so that the related webhook event is fired accordingly and you can send customers a notification about upcoming recurring orders associated with subscriptions.
To automatically generate order subscriptions based on a source order's line items with frequency you need to associate a subscription model with your market. The source order is considered the subscription's first run, some of its information is copied (e.g. addresses, customer payment source, etc.), the involved order subscription items are created and associated with the generated order subscriptions, and — upon successful recurring order copy — the target order is placed using the saved customer payment source (if still valid).
In between each run you can edit the subscription (e.g. changing its frequency, expiration date, status etc.) to dynamically manage the next occurrences.
By default, automatically generated order subscriptions are directly activated, unless differently specified at the subscription model level.
When changing the subscription's frequency make sure to also manually update the next_run_at attribute with the correct time in the future, otherwise the next subscription run couldn't happen when expected.
When manually creating an order subscription both types of order factories can be used.
If no subscription model is associated with the market, manually created order subscriptions — simply based on a source order that not contains any line items with frequency — rely on order copies to create recurring orders. In this case, all the source order's information and line items are cloned into the target order, according to the frequency set for the order subscription. An attempt to place the copied order is done at the end of the process. You can set the place_target_order option as false at creation time if you prefer to place created orders manually.
By default, manually generated order subscriptions activate from a placed source order, which is considered the subscription's first run. In this case, the subscription is marked as active and the next run will be scheduled on the current timestamp. If you want full control over the order subscription, you can specify the activate_by_source_order option as false at creation time. This way, you are not limited to placed source orders (source order status isn't checked), but must define manually the starts_at time (expires_at time is optional). Also, remember to use the _activate attribute to activate the subscription, otherwise it will miss the next run.
Order subscriptions that rely on recurring order copies can be created manually too (e.g. if you need to generate subscriptions for some source order's line items only). In this case, you need to set also the relationship with an existing subscription model and a source order, create and associate the order subscription items, and specify the customer payment source.
Check the related to learn more about how to generate and automatic subscriptions from a source order.