Postman collections

Use the Sales Layer Postman collection to test the DAM and Catalog REST APIs from a controlled local workspace.

The collection is built for prospects, customers, and implementation partners who want to validate connectivity, authentication, headers, query parameters, and complete request flows before building an integration. It includes ready-to-run examples for every endpoint exposed by the current OpenAPI specifications, for both DAM resources (images and files) and every Catalog resource.

The OpenAPI reference remains the source of truth for the full current endpoint surface.

Requests are organized to match the API reference. Read-only requests come first; write requests are grouped per resource and clearly labeled.

The Accept-Language, $select, $filter, $orderby, $expand, $top, and $skip values in each request are starting examples. Field names such as prod_ref, cat_ref, or frmt_ref depend on the account. Confirm the available fields with the matching metadata request before adapting a query or a write payload.

Import both files into Postman:

The environment template does not contain a real API key. The apiKey variable is intentionally empty and marked as a secret.

1. Open Postman.
2. Select Import.
3. Import sales-layer-rest-api.postman_collection.json.
4. Import sales-layer-rest-api.postman_environment.json.
5. Select the Sales Layer API - Template environment in the top-right environment selector.
6. Open the environment and set the Current value of apiKey to the API key provided by Sales Layer.
7. Save the environment.

Keep API keys out of exported files, screenshots, shared workspaces, and source control.

Start with read-only requests that do not modify data:

1. Run Setup checks / Catalog service metadata.
2. Run Setup checks / DAM list first page.
3. Run Catalog REST API v2.0 / Metadata / Products metadata.
4. Run Catalog REST API v2.0 / Products / List products.
5. Run DAM REST API v2.0 / Images / List images with pagination.
6. Run DAM REST API v2.0 / Files / List files with pagination.

These requests verify the base URL, API key, and account access without creating, updating, or deleting resources.

Write requests are labeled (write) and live alongside the read requests for each resource. Run them only against a test account.

The Catalog create requests include a test script that captures the created identifier into the matching environment variable (catalogProductIdentifier, catalogCategoryIdentifier, catalogVariantIdentifier, or customEntityItemId). This lets you run a full lifecycle in order, for example:

1. Create category (write) — stores the new id in catalogCategoryIdentifier.
2. Create product (write) — uses that category and stores the new id in catalogProductIdentifier.
3. Update product (write) — sends a partial update.
4. Get product by identifier — confirms the change.
5. Delete product (write) — removes the test product.

DAM images and files work differently: their reference (filename) is not generated by the server, so there is nothing for a test script to capture. Instead:

1. Edit the Create image (write) or Create file (write) request body and replace the placeholder example.com URL with a real, publicly reachable asset.
2. Set damImageReference or damFileReference to the filename at the end of that URL — that filename becomes the reference.
3. Run Create, then Get, Update, and Delete in order, using the same reference variable throughout.

Before running write requests, confirm that the account and environment are safe for testing.

Catalog fields vary by account configuration. Use the metadata requests before building specific queries or write payloads:

GET /catalog/$metadata
GET /catalog/Products/$metadata
GET /catalog/Categories/$metadata
GET /catalog/Variants/$metadata
GET /catalog/AttributeSets/$metadata
GET /catalog/CustomEntities/$metadata
GET /catalog/CustomEntities('{denominator}')/$metadata

After confirming available fields, adjust $select, $filter, $orderby, $expand, $top, and $skip values in Postman as needed.

The collection sends the API key through Postman's collection-level authentication:

X-API-KEY: {{apiKey}}

Requests also use:

Accept: application/json
Content-Type: application/json
Accept-Language: {{acceptLanguage}}

Content-Type is only required for requests with a JSON body. Accept-Language supports exact language or locale codes; q-factor weighting and the wildcard * are not supported.

If a request fails, check the following:

• The Sales Layer API - Template environment is selected.
• apiKey has a current value in the selected environment.
• baseUrl is https://api2.saleslayer.com.
• The API key is valid for the account and API area being tested.
• Catalog identifiers and field names exist in the current account metadata.
• DAM get, update, and delete requests use a valid damImageReference or damFileReference (the filename), matching an asset that actually exists in the account.
• DAM create and update requests point at a real, publicly reachable URL — the placeholder example.com URL does not resolve and always fails validation.
• Rate limiting may apply (50 requests per 10 seconds). Retry after a short delay if you receive a 429 response.

• Authentication
• Headers
• Base URL
• Rate limiting
• API reference overview