# Versioning and deprecation policy

> How the v1 Data API changes: what ships without notice, what is announced in the changelog first, the deprecation stages, and the legacy paths still supported.

*Source: https://shopsavvy.com/data/documentation/versioning* · Part of the [ShopSavvy Data API documentation](https://shopsavvy.com/data/documentation.md)

---

The API is versioned in the path: every endpoint lives under `https://api.shopsavvy.com/v1`. The current and only version is **v1**.

**What can change within v1 without notice** (write your client to tolerate these):

- New endpoints, new optional parameters, and new fields on response objects. Ignore fields you don't recognize.
- New values in open-ended fields, such as a new `condition_grade`, a new webhook event type you have not subscribed to, or a new `match.by` value.
- More specific error `message` and `action` text. Error `code` values do not change.

**What is announced first:** anything that could break a working integration, such as removing or renaming a field or endpoint, changing a field's type, or tightening a request limit. These are posted in the [changelog](https://shopsavvy.com/data/changelog) (also available as an [RSS feed](https://shopsavvy.com/data/changelog.xml)) before they take effect, and marked deprecated in these docs while the old behavior still works. A change that cannot be made compatibly ships under a new version path, with v1 kept running alongside it.

| Stage | What it means |
|-------|---------------|
| Current | Documented and recommended. |
| Deprecated | Still works and still supported, marked in these docs and the changelog with its replacement. Move to the replacement. |
| Removed | Answers with an error. Only after a deprecation period announced in the changelog. |

## Legacy paths

Older SDK versions call these paths. They are supported and behave exactly like their replacements; use the replacements in new code.

| Legacy path | Use instead |
|-------------|-------------|
| `GET /v1/products/details` | `GET /v1/products` |
| `GET /v1/products/history` | `GET /v1/products/offers/history` |
| `POST /v1/products/schedule` | `PUT /v1/products/scheduled` |
| `DELETE /v1/products/schedule` | `DELETE /v1/products/scheduled` |

The price-history parameters `start_date` and `end_date` are likewise accepted as aliases for `start` and `end`.