Recipes

Use these recipes as starting points for common Sales Layer REST API workflows.

Read only the catalog fields you need

Use $select to reduce payload size for catalog exports and synchronization jobs.

curl -X GET 'https://api2.saleslayer.com/catalog/rest/Catalog/Products?$select=prod_ref,prod_title' \
  -H 'X-API-KEY: YOUR_API_KEY'

Select only the fields required by the downstream system. This makes integrations faster and easier to troubleshoot.

Filter before processing

Use $filter to narrow results before they reach your integration.

curl -X GET 'https://api2.saleslayer.com/catalog/rest/Catalog/Products?$filter=contains(prod_title,%27shoe%27)' \
  -H 'X-API-KEY: YOUR_API_KEY'

Filtering at the API level is usually more efficient than retrieving a broad dataset and filtering it client-side.

Synchronize large datasets

For list operations, process results in pages and store progress between runs.

Use token-based pagination with $skipToken when a Catalog endpoint supports it and returns continuation links. Use $top and $skip for DAM and offset-style endpoints.

curl -X GET 'https://api2.saleslayer.com/dam/image?$top=100&$skip=0' \
  -H 'X-API-KEY: YOUR_API_KEY'

Keep the page state, retry count, endpoint, status code, and request timing in integration logs.

Detect catalog changes

Use Catalog changelog endpoints when an integration needs to identify changes since a previous synchronization.

Recommended pattern:

Read the relevant changelog endpoint.
Store the last processed checkpoint in your integration.
Fetch changed resources by identifier when the integration needs full records.
Apply bounded retries for temporary failures.

Handle failures consistently

Use status codes to decide whether to fix the request, retry later, or escalate the issue.

400, 401, 403, 404: review request, credentials, permissions, or identifiers.
409: retry only when the conflict is expected to be temporary.
500: use bounded retries with backoff.