# Best practices

Use these practices to build reliable and maintainable integrations with Sales Layer REST APIs.

## Use metadata endpoints

Catalog metadata endpoints describe available fields, resource structures, and relationships.

Use metadata before building dynamic requests, especially when working with products, variants, categories, attribute sets, or custom entities.

Recommended metadata endpoints include:


```http
GET https://api2.saleslayer.com/catalog/rest/Catalog/$metadata
GET https://api2.saleslayer.com/catalog/rest/Catalog/Products/$metadata
GET https://api2.saleslayer.com/catalog/rest/Catalog/Categories/$metadata
GET https://api2.saleslayer.com/catalog/rest/Catalog/Variants/$metadata
```

Cache metadata responses when possible, and refresh them when the account configuration changes.

## Minimize response payloads

Use `$select` to request only the fields needed by the integration.

This reduces transfer size, speeds up processing, and makes logs easier to inspect.


```http
GET https://api2.saleslayer.com/catalog/rest/Catalog/Products?$select=prod_ref,prod_title
```

## Filter before processing

Use `$filter` to reduce the amount of data returned by the API.

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

## Use pagination for large datasets

Use pagination for list operations.

For large Catalog datasets, prefer token-based pagination with `$skipToken` when the endpoint supports it and returns continuation links.

For DAM and endpoints that use offset-style pagination, use `$top` and `$skip`.

## Respect rate limits

Design clients to stay below documented rate limits and retry temporary failures with bounded backoff.

See [Rate limiting](/guides/rate-limiting).

## Protect credentials

API keys must be treated as secrets.

Do not expose them in browser code, public repositories, screenshots, logs, or customer-facing error messages.

See [Authentication](/guides/authentication) and [Headers](/guides/headers).

## Handle responses intentionally

Use HTTP status codes to drive client behavior:

* Treat `200`, `201`, and `204` as successful outcomes.
* Treat `400`, `401`, `403`, and `404` as errors that usually require request, configuration, or permission changes.
* Treat `409` as a state conflict, especially for DAM resources being processed.
* Treat `500` as potentially temporary, but use bounded retries.


## Build observable integrations

Log enough information to troubleshoot safely:

* API domain and endpoint.
* HTTP method and status code.
* Request timing.
* Retry count.
* Page or continuation state.
* Correlation identifiers when available.


Do not log full API keys or sensitive payload values.