Overview Authentication and permissions Making requests Retrieve basic site information

Idempotency-Key header Rate limits Responses & error handling Upgrade Changelog Glossary FAQ

Overview GET: Retrieve all inventory GET: Retrieve specific inventory POST: Adjust stock quantities

Overview POST: Create an order POST: Fulfill an order GET: Retrieve all orders GET: Retrieve a specific order

Overview About product attributes Managing attributes POST: Create a product POST: Create a product variant POST: Upload a product image GET: Retrieve all Store Pages GET: Retrieve all products GET: Retrieve specific products GET: Product image upload status POST: Assign a product image to variant POST: Reorder a product image POST: Update a product POST: Update a product variant POST: Update a product image DEL: Delete a product DEL: Delete a product variant DEL: Delete a product image

Overview GET: Retrieve all profiles GET: Retrieve specific profiles

Overview GET: Retrieve all transactions GET: Retrieve specific transactions

Overview POST: Create a webhook subscription POST: Update a webhook subscription GET: Retrieve all webhook subscriptions GET: Retrieve a specific webhook subscription DEL: Delete a webhook subscription POST: Send test notification POST: Rotate a subscription secret

Commerce API upgrades

Each Commerce API resource has an independent version number, where the current version number is listed in the resource's overview page. Versions are specified in request URIs per the following format:

Format

https://api.squarespace.com/{api-version}/{resource-path}

Examples

https://api.squarespace.com/v2/commerce/products
https://api.squarespace.com/1.0/commerce/orders

Versioning methodology and breaking changes

From v2 endpoints onwards, our versioning methodology has evolved to provide more stability and less overhead for developers.

Pre-v2 (1.0 and 1.1)

Squarespace endpoints pre-v2 used a Semantic Versioning format (Major.Minor), where minor updates sometimes introduced breaking changes.

v2 onwards

Starting with v2, Squarespace now uses a non-SemVer approach, using integers: v2, v3, v4, etc. From this version onwards, non-breaking changes are added to the existing version without incrementing the version string. A version increment is only triggered by a breaking change that requires developers to update their code.

The following types of changes will not result in a version increment. Any code that interacts with the Squarespace APIs must be able to handle the following types of changes:

Additive response contents: New fields or objects in a JSON response.
Relaxed constraints: Making a required field optional, or loosening of validation rules (e.g. a string with a maximum length of 50 is expanded to 100).
New HTTP methods: Allowing new HTTP methods for endpoints that previously did not support them.
Bug fixes: Bug fixes that do not result in breaking changes.

All changes are, nonetheless, registered in our changelog, even if they do not require a version bump.

Current versioning per resource path

Resource path	Latest version	Legacy versions
`/products`	`v2`	`1.1`, `1.0`
`/inventory`	`1.0`	`N/A`
`/orders`	`1.0`	`N/A`
`/profiles`	`1.0`	`N/A`
`/transactions`	`1.0`	`N/A`
`/webhook_subscriptions`	`1.0`	`N/A`

Legacy API versions

Squarespace supports legacy API versions for an extended period. We provide significant advance notice before deprecating any version. Supported legacy versions will be documented per API, including the information you need to upgrade your applications.