Amazon Pinpoint’s support cutoff was October 30, 2026. AWS’s current migration guide distinguishes retired engagement features from message-sending capabilities that continue. For an application owner checking a transactional send on November 2, the useful starting point is the actual API request and how it identifies recipients.

Conceptual illustration of two message-routing paths beside a developer’s desk and an October calendar.
Conceptual illustration of two message-routing paths beside a developer’s desk and an October calendar.

Read the operation and recipient path together

The migration guide says SendMessages continues for channels available to the account. It lists SendUsersMessages and sending to a stored endpoint ID as unsupported. SMS, voice and email sending remain available to existing customers; AWS points new SMS or voice use to End User Messaging and new email use to SES. Account eligibility therefore belongs beside the channel and operation in the review.

If the replacement email path uses SES, verify its regional sending interface, sender identity and access status before moving traffic.

AWS migration guide: capabilities after October 30, 2026

The Messages API reference still documents both Addresses and Endpoints in the request schema. Endpoints is keyed by endpoint ID. Read that schema alongside the dated migration guidance: the presence of a field in the reference does not establish continuing support for an endpoint-ID send path.

Messages API reference: request schema and response results

Make one inventory row per sending path

  • Record the application, responsible owner, AWS account, region and channel.
  • Identify the exact operation called by the running application or its messaging wrapper.
  • Record whether the recipient is supplied directly or resolved through a stored endpoint ID; redact personal data in review notes.
  • Keep account eligibility, template dependencies and the most recent controlled result beside that path. Mark unknowns explicitly.

Consider a fictional retailer with two receipt jobs. One builds a SendMessages request with a direct address. Another passes an endpoint identifier through a shared library. Start with separate rows even if both jobs display the same product name in a dashboard. The first path still needs its account and channel conditions checked; the second has a dependency specifically identified in the retirement guide.

This is an invented code-review example. It does not establish that a particular account can send, that a message was delivered or that changing one field completes a migration. Trace the call through wrappers and configuration before choosing the next step. Keep credentials and real recipient details out of shared screenshots.

Verify the outcome separately

AWS says message-event delivery to Kinesis or Data Firehose and message metrics to CloudWatch continue, while analytics and KPI APIs are unsupported. Use the documented observability path applicable to your workload when planning verification.

With the application owner’s approval, define a harmless message to a controlled test recipient and record the expected outcome before sending. Retain the operation, redacted request shape, timestamp, response and available delivery evidence. A successful result for one row should not mark every other path complete. No AWS account, API request, migration or delivery was tested for this guide.

Check the recipient dependency