Changelog

• Launched Resent developer docs with a Getting started overview.
• Added Messaging API guides for email, SMS, and WhatsApp.
• Published Authentication, Rate limits, SDKs, MCP, Domains, and Webhooks pages.

We clarified the description of the per-contact contactRealTimeConsent field, and the behavior when a contact drops in and out of the real-time consent production model was documented in detail.

You can now set custom UTM parameters on marketing campaigns. When a campaign is sent, utm_source, utm_medium, utm_campaign, and utm_content are appended to every tracked link, so downstream analytics attribute traffic correctly.

The sendAt header now honors per-contact tracking consent. If a contact has opted out of open tracking, the tracking pixel is omitted from that recipient’s message even when the template enables it.

The Resent CLI (@resent/cli) has a new major version, 2.0.0, which introduces breaking changes. If you are on v1.x or earlier, migrate to 2.0.0 — some commands may not work as expected on older versions.

Upgrade:

$
npm install -g @resent/cli@latest
$
# or
$
brew upgrade resent/tap/resent

GET /crm/deals now documents three additional query filters, so you can narrow results server-side instead of fetching every deal and filtering client-side:

• filters[attributes.deal_owner] — filter by deal owner (pass the owner’s account email)
• filters[attributes.deal_stage] — filter by stage (pass the stage ID)
• filters[attributes.pipeline] — filter by pipeline (pass the pipeline ID)

New endpoints and fields have been added for managing consent groups and generating wallet pass installation URLs.

Consent Groups represent categories of contact opt-in/opt-out preferences:

• GET /contacts/consent-groups — list all consent groups. Paginated; filterable by id, name, and signupMode.
• POST /contacts/consent-groups — create a consent group.
• PUT /contacts/consent-groups/{id} — update name, description, or signup mode.
• DELETE /contacts/consent-groups/{id} — remove it from all associated contacts.

API keys can now declare scopes — the specific permissions a key grants. Scopes are embedded in the key so your integration only gets the access it actually needs.

What’s new

• Request granular permissions per key (e.g. email:send, domains:read, contacts:write, crm:read).
• New keys default to email:send and domains:read.
• Manage scopes from the dashboard or CLI:
  • resent key available-scopes lists every supported scope.
  • resent key update --scope <scope> adds scopes to an existing key (repeatable).

We’ve released the next major version of our official SDKs. These are opt-in major releases with breaking changes — your existing integrations are not affected unless you upgrade.

Why this release

Most breaking changes come from an effort to make endpoints, parameters, and models more self-descriptive — so names and shapes convey intent for both developers and AI agents.

Effective: 30 October 2026

The Update Multiple Contacts endpoint (POST /contacts/batch) will be deprecated on 30 October 2026. It is being replaced by the newer and more scalable POST /contacts/import API.

What you need to do

• Migrate all bulk-update operations to /contacts/import.
• The deprecated endpoint may stop functioning after the deprecation date.

Breaking changes

• Get contact attributes — The value (integer) field in category-type attribute enumerations now returns 0 for non-numeric values (e.g. language codes "en", "fr"). Clients using value as a unique identifier must migrate to the new valueStr field.

Added

Breaking changes

• Batch track events (POST /events/batch) — The request body schema has changed. The array of events must now be wrapped in an object under an events key. Previously accepted: [{...}, {...}]. Now required: {"events": [{...}, {...}]}. event_name and identifiers are now explicitly required on each event object.

This release reflects a major rework of the OpenAPI specification to bring it in line with actual API behavior. Some changes correct inaccuracies between the spec and responses, so some generated SDK types will change.

Breaking changes

• Process endpoints — Import info fields (invalid_emails, duplicate_email_id, etc.) are now typed as string (URL to a CSV report) instead of integer.
• Webhooks — Event names corrected: hardBounces → hardBounce, listAdditions → listAddition.
• Domain creation (POST /domains) — Domain name validation changed from a custom regex to format: hostname.

• Process endpoints — duplicate_email_id is now typed as a string (URL to a CSV file) instead of an integer. The legacy in_process status value is now handled correctly across all SDKs.
• Event endpoints — contact_properties and event_properties now accept boolean values in createEvent and createBatchEvents.
• Contact endpoints — attributes now accepts plain integers in createContact and updateContact.

WhatsApp — New template fields

Two new fields are now supported when creating WhatsApp templates:

• category — template category (MARKETING, UTILITY, or AUTHENTICATION).
• languageCode — BCP-47 language code for the template body.

Events API — New GET endpoint

The Resent MCP server has been updated with improved security, simplified maintenance, and rate limiting.

What changed

• Authentication method — MCP tokens are no longer passed in the URL. They are now transmitted securely via the HTTP Authorization: Bearer <token> header. Previous URL patterns containing /{token} are no longer valid.
• Auto-generated tools — MCP tools are now automatically generated from the Resent OpenAPI specification, eliminating discrepancies between the API and MCP server.
• Rate limiting — Request limits have been added to protect services from abuse.
• New tool support — Integration guides now cover Windsurf, VS Code (GitHub Copilot), and Claude Code in addition to Cursor.