Salesly API

Changelog

All notable changes to the Salesly Developer API.

v1.1.0 — 2026-03-05

Breaking Changes

RESTful URL redesign — All endpoints have moved to RESTful patterns:

BeforeAfter
POST /enterprise/createPOST /contacts
POST /enterprise/listGET /contacts
GET /enterprise/readGET /contacts/{identifier}
PUT /enterprise/editPUT /contacts/{identifier}
DELETE /enterprise/deleteDELETE /contacts/{identifier}
POST /enterprise/multiple-createPOST /contacts/batch

The same pattern applies to opportunities, orders, products, and product categories. See each resource's documentation for the updated URLs.

Response envelope — All responses now wrap data in a data key:

// Before
{ "id": 1, "name": "ACME" }

// After
{ "data": { "id": 1, "name": "ACME" } }

Standardized error format — Errors now follow a consistent envelope:

{ "error": { "type": "not_found", "message": "Contact not found." } }

Pagination — List endpoints changed from POST to GET with query parameters. The pagination format is now { "data": [...], "pagination": {...} }.

New Features

  • Idempotency — Send Idempotency-Key header on write requests to safely retry operations
  • Request tracing — All responses include X-Request-ID header
  • Per-key rate limiting — 120 req/min (read), 30 req/min (write)
  • Webhook signatures — Webhook payloads are signed with HMAC-SHA256
  • Audit logging — All API requests are logged for audit purposes
  • OpenAPI spec — Machine-readable API specification at /openapi/v1.yaml

Improvements

  • ISO 8601 date format in all responses
  • Consistent 201 Created status for resource creation
  • has_more field in pagination for easier iteration
  • Better validation error messages with field-level details

v1.0.0 — 2025-03-01

Initial release of the Salesly Developer API.

  • Contact CRUD + batch create
  • Opportunity CRUD + batch create
  • Order CRUD + batch create
  • Product CRUD + batch create
  • Product Category CRUD
  • API key authentication

Deprecation Policy

  • Deprecated features will be announced at least 90 days before removal
  • Deprecated endpoints will include an X-Deprecated header in responses
  • Breaking changes will only be introduced in new major versions