Skip to main content

Deprecations

This page tracks deprecated API endpoints and their scheduled removal dates. If you are integrating against BlueSender for the first time, do not use the endpoints listed here — use the replacement listed in each entry.

Deprecated endpoints​

POST /send-message​

FieldValue
Status410 Gone (sunsetted 2026-05-01; code removal in next release)
Deprecated2025-02-06
Sunset2026-05-01
ReplacementPOST /crm/webhook

Reason: Endpoint is unused. All CRM integrations use /crm/webhook, which provides better payload flexibility, signature verification, and status updates.

Migration: Update your webhook URL from /send-message to /crm/webhook and add contactId to the payload. The legacy endpoint required (locationId, number, message); /crm/webhook requires (locationId, contactId, message-or-attachments) and treats number as optional (resolved from the contact when omitted). See the HTTP Webhooks reference for the full payload format.

POST /crm/send-message​

FieldValue
Status410 Gone (sunsetted 2026-05-01; code removal in next release)
Deprecated2025-02-06
Sunset2026-05-01
ReplacementPOST /crm/webhook

Reason: Endpoint is unused. Functionally identical to /crm/webhook but with stricter field requirements.

Migration: Update your webhook URL from /crm/send-message to /crm/webhook. No payload changes required.

Removed field aliases on POST /crm/webhook​

In release 1.19.13 the wider field-alias set previously accepted on /crm/webhook (and its two path aliases) was removed. The endpoint now accepts only the canonical CRM Conversation Provider — Outbound Message schema, which is exactly the shape documented on HTTP Webhooks.

The removed aliases had accumulated during early debug commits in February–March 2025 and were never used by a real integrator in production — verified by a server-log scan over the prior 3 months (zero matches across 216 webhook requests).

FieldRemoved alias paths
locationIdlocation.id, accountId
contactIdcontact.id
messageIdid, message.id, payload.id
messagebody, text, message.body, payload.body, data.body, raw
phonenumber, toNumber, toPhone, toPhoneNumber, to, contact.phone, contact.phoneNumber, customer.phone, payload.phone, payload.number, data.phone, data.number
attachmentspayload.attachments, data.attachments, message.attachments
conversationIdmessage.conversationId, payload.conversationId, conversationProviderId, payload.conversationProviderId

Migration. Send the canonical fields at the top level of the JSON body. Existing integrations that already use the documented shape are not affected. Requests that relied on one of the removed aliases now fail validation with 400 MISSING_REQUIRED_FIELDS.

accountId note. The legacy accountId alias previously resolved as locationId for routing purposes but silently disabled per-message status callbacks (the message-location cache was only keyed by locationId). The endpoint is therefore now fail-fast instead of silently degraded for those requests.

type field tightening. The endpoint previously logged type but ignored its value entirely, so an Email-typed payload would flow through the iMessage / SMS pipeline. As of 1.19.13 type is optional, and when present must equal "SMS" — Email (and any other value) is rejected with 400 UNSUPPORTED_MESSAGE_TYPE. Production traffic was 216/216 SMS prior to this change, so no live integrator is affected.

Response headers on deprecated endpoints​

Deprecated and sunsetted endpoints return the following response headers per RFC 8594:

  • Deprecation: @<unix-timestamp> — when the endpoint was deprecated.
  • Sunset: <HTTP-date> — when the endpoint stopped accepting traffic.
  • Link: <url>; rel="deprecation" — link to this page.

If your client logs response headers, you can detect deprecated calls without polling this page.

Removal process​

  1. Endpoints are marked deprecated with logging and the response headers above.
  2. A minimum 90-day notice period runs between the deprecation and the sunset date. Specific endpoints may receive a longer notice period — see the table above for actual dates.
  3. On the sunset date the endpoint starts returning 410 Gone with the response headers above.
  4. The 410 Gone response is kept for one release cycle so late callers get a clear signal, after which the route and handler code are removed entirely.
  • Versioning policy — overall compatibility guarantees and how breaking changes are signalled.
  • HTTP Webhooks — current endpoints and their request/response shapes.