Commerce Layer lets you export resources in JSON (default) or CSV formats. To do that, you need to create a new , specify the resource_type you want to export, and the format of the exported file. Optionally, you can also specify the relationships you want to include, apply some filters to narrow the exported data, and decide to skip some redundant attributes.
To export a CSV list you need to set the format attribute to csv. Otherwise, if the format is not specified, your data will be exported using the default format (JSON).
The process is asynchronous and you can poll the status attribute to check the export progress. As soon as an export is created you can check the number of items that are going to be exported by inspecting the records_count attribute. If you try to export a resource with records_count = 0, an error is returned.
Resource relationships are exported by default with their IDs, appending the _id suffix to the name of the related resource (e.g. "price_list_id": "xYZkjABcde"). Some relationships can also be exported as a nested object if specified as valid included associations.
Attachment URL
Once the export process is completed, the results are compressed (gzip) and uploaded to an external storage service (currently Amazon S3). You can download the exported data using the link exposed in the attachment_url attribute.
External storage service URLs expire in 5 minutes. You need to uncompress (gunzip) the file in order to read the data back. If the exported data URL is expired you can just fetch the completed export to get a new working one.
Export limits
Maximum export size
There is no limit on the total number of resources you can export, but the single batches are subject to some soft limits: the records_count must be a maximum of 10000 records, otherwise the export will be rejected at the time of creation.
Concurrent exports
The maximum number of concurrent exports (i.e. exports whose status is pending or in_progess) allowed per organization is 10.
If you absolutely need to export any of the supported resources in one go, overriding the API limits above, you can leverage the power of our CLI export plugin (see example). Alternatively, you can also perform a using our Metrics API (at the moment limited to , , and ).
Supported resources
At the moment, exports are available for almost all of the resources exposed via API. Please find some examples of how to export them here below.
With very few exceptions (e.g. shipments, transactions, customer payment sources, etc.), exported outputs (both in JSON or CSV format) can be used as inputs for the imports API. If you're using the export + import features to duplicate your dataset records (e.g. to migrate your test data to your live environment) you may need to skip some redundant attributes. Specifically, if you want to export resources from an organization and import them into a different one, make sure to set the export's dry_data attribute to true in order to avoid ID conflicts. In that case, we also suggest not to use fields when exporting the data you plan to re-import elsewhere (use includes instead).
It's possible to include one or more relationships of the exported resource using the includes attribute. Relationships will be exported as an object if singular (has_one or belongs_to), or as an array of objects if multiple (has_many) — check Commerce Layer API data model for more information on how resources relate to each other.
If you use the CSV format to export your data the output will have the relationship attributes flattened together with the parent resource ones. As a result, you'll find the resource attributes repeated on multiple lines, with relationship ones appended at the end. When exporting tags together with a tagged resource the cells belonging to the tags.id and tags.name columns contain a string with the list of IDs/names, comma separated. In general, using CSV is fine for simple exports (resources with a few attributes and no relationship included), otherwise we strongly recommend using JSON.
CSV format supports only one level of relationship (e.g. if you try to include line_items.line_item_options when exporting orders, only the line items will be exported).
Supported associations
All of the valid resource relationships can be included when exporting. Please refer to the specific resource page in the Core API reference to check which relationships you can include when exporting it.
In case you specify an invalid include for the exported resource, an error is raised before creating (and starting) the export.
Selecting fields
When exporting resources, you can select the resource fields to be exported in advance by specifying the fields attribute as an array of values.
For the main exported resource you can pass fields using the plain attribute names. For any related association's attribute use the dot notation (the same used when including associations), i.e. . followed by the field name.
If you want to export all the fields of a resource, use the asterisk * (works both for the main and related resources).
For example, if you want to export SKUs with their code and name plus some specific fields of the associated prices and stock items and all the fields of the associated shipping category, use a field array like this:
Some attributes which are potentially sensible (e.g. any kind of credentials) will not be included in the exported file also if you explicitly specify them in the fields array.
Fields vs. includes
Specifying includes is completely redundant when using fields since any association's related attribute listed among the fields automatically includes the related resource. This also means that:
If you specify a field using an invalid related association, an error is raised before creating (and starting) the export.
If you include an association that has no corresponding related field, its data will not be exported.
As a general rule of thumb, use includes when you want to export all the fields of the included resource and use fields when you want to export specific fields of the resource only.
Filtering exported data
When exporting resources, you can fine-tune the data to be exported by applying some filters (both to the resources and their relationships) using the filters attribute:
To compose the filter predicate you just need to follow the same syntax you use when filtering a collection of resources — {{attributes}}_{{matcher}}. You must specify filtering rules as a valid JSON object. List values for the *_in matcher need to be expressed as arrays (as in this example).
You might want to compact exported data by removing some redundant attributes from the final JSON or CSV output. To do that, set the dry_data specific boolean attribute to true — the following attributes and values will be skipped:
The main resource IDs.
The timestamp attributes (created_at and updated_at).
Any empty or null attribute value (working when exporting in the JSON format only).
All the formatted amounts other than cents (e.g. for prices, orders, etc.).
Examples
Exporting some fields of a filtered list of addresses (JSON)
The following request creates an export of a list of addresses in JSON format, filtered by country code and city, fetching just the full_name and full_address fields:
Exporting a filtered list of bundles with SKU lists and SKU list items (CSV)
The following request creates an export of a list of bundles and their associated SKU lists and SKU list items in CSV format, filtered by SKU list name:
Exporting some fields a filtered list of customer addresses with addresses and customers (JSON)
The following request creates an export of a list of customer addresses in JSON format, filtered by customer's email, fetching just the associated customer email and address full_address fields:
Exporting some fields of a filtered list of customers with customer subscriptions (JSON)
The following request creates an export of a list of customers in JSON format filtered by email, fetching all the customer attributes and just the customer subscription reference field:
Exporting a filtered list of orders with customer, addresses, line items, line item options, payment method, and refunds (JSON)
The following request creates an export of a list of orders dry data with the associated customer, addresses, line items, line item options, payment method, and refunds in JSON format, filtered by status, country code, and the date and time at which they were placed:
Exporting a filtered list of order subscriptions with order subscription items and customer payment source (JSON)
The following request creates an export of a list of order subscriptions with the associated order subscription items and customer payment source in JSON format (skipping the redundant attributes), filtered by customer email:
Exporting some fields of a filtered list of prices with price tiers (CSV)
The following request creates an export of a list of prices with associated SKUs and price tiers in CSV format, fetching just the price's amount_cents and the associated SKU's code, price tier's type and price_amount_cents fields, filtered by the associated price list's currency code:
Exporting a filtered list of SKUs with prices, price tiers, stock items, and tax categories (JSON)
The following request creates an export with a list of SKUs, with the associated prices, price tiers, stock items, and tax categories in JSON format (skipping the redundant attributes), filtered by SKU name:
Exporting some fields of a filtered list of stock items with SKUs and stock location (CSV)
The following request creates an export of a list of stock items and the associated SKUs and stock location in CSV format (skipping the redundant attributes), filtered by stock item quantity, fetching just the stock item's quantity, and the associated SKU's code and stock location's name fields:
Exporting some fields of a filtered list of stock transfers with SKUs and stock locations (CSV)
The following request creates an export of a list of stock transfers (filtered by their quantity) with the associated stock locations and SKUs in CSV format (skipping the redundant attributes), fetching just the stock transfer's quantity, the origin and destination stock location name, and all the SKU's fields:
Exporting some fields of all the SKUs tagged with at least one of two tags (JSON)
The following request creates an export of all the SKU associated with the tag identified by the "geJmexflJQ" ID or by the "XEqZPxfPam" ID, fetching just the code and tag name fields, in JSON format:
When filtering a list of tagged resources by tag(s) the only allowed predicates are tags_id_in and tags_id_not_in.
Exporting more than 10K orders using the CLI
The following command exports all the approved orders whose amount is over $1000 (including the associated customer, line items, and tags) in JSON format into a single file and saves it to a specified path:
On success, the CLI prompts this message on your terminal, separating the single exports and showing some basic information about the completed processes:
When you create an export, it tries immediately to start the exporting process, entering the in_progress status. In case the async queue is saturated, the export remains pending until it gets a chance to be processed.
If an export gets stuck in the in_progress status for any reason, you can mark it as interrupted by patching it with the _interrupt trigger attribute set to true. In case an export fails instead, it is automatically moved to the interrupted status and the errors_log attribute gets filled with the runtime error that caused the interruption.
Webhooks for exports
You can also leverage Commerce Layer real-time webhooks mechanism, listen to exports.create, exports.start, exports.complete, exports.interrupt, or exports.destroy and react properly.
