🚧 Historical orders
This endpoint should only be used to import historical orders into Voucherify. For on-going synchronization, the update order endpoint should be used. This is critical because this endpoint does not store events or launch distributions. The orders will also have a
created_atdate that’s assigned when they’ve been imported to Voucherify. To keep track of the actual order creation date, add an order metadata in ISO 8601 date or date time format to each imported order.
There can be only a single on-going order import per tenant per project at a given time. The user can schedule more imports but those extra imports will be scheduled to run in sequence one by one.
There is a 2000 limit of orders per one request.
There are no notifications on the Dashboard because this import is launched via the API.
If you import orders with customers, then a logic will be scheduled responsible for placing these customers into segments and refreshing the segment’s summary. Consequently, this update will trigger
No webhooks are triggered during the import of orders - for both orders and upserted products / SKUs.
Distributions based on Order Update, Order Paid, Order Created and Order Cancelled. In other words if you have a distribution based on Order Paid and you import an order with a PAID status, the distribution is not going to be triggered.
No events are created during the import of orders - for both orders and upserted products / SKUs. In other words you won’t see any events in the Activity tab in the Dashboard such as Order created or Order paid. If you are additionally upserting products / SKUs, then you won’t see the Product created events listed, etc.
Earning rules based on Order Paid won’t be triggered.
This API request starts a process that affects Voucherify data in bulk.
In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.
The result will return the async ID. You can verify the status of your request with GET Async Action endpoint.