Unsend has rebranded to Usesend.com. The change includes new APIs, SDKs, and domain endpoints while retaining the existing payload structure. This article provides verified technical detail, example code, a concise migration checklist, and testing guidance to support developer teams and implementers.
The previous name Unsend introduced ambiguity in product intent. The new identity, useSend, aligns naming with common developer conventions.
Unsend felt like the opposite of sending… as a big fan of React, useSend just hits home. The .com domain is the bonus.
Koushik KM, developer of useSend, stated that Unsend felt like the opposite of sending and that useSend aligns with React naming patterns with the .com domain providing additional credibility. This naming and domain consolidation supports clearer adoption and enterprise use.
The rebrand is implemented across the platform and the ecosystem. Key changes are as follows.
All public request endpoints now resolve under the usesend.com domain. Any hard coded references to unsend.dev should be validated and updated.
The official npm package is published as usesend-js. Install commands and package manifests must be updated accordingly.
npm i usesend-jsimport { UseSend } from "usesend"; Environment variable names and configuration references should be standardized to reference useSend credentials and domains. Confirm API key names in CI and deployment systems.
The email payload format is preserved. Existing email request bodies remain compatible which reduces refactor scope.
Below is an exact before and after snippet to include in migration documentation or release notes.
Before Unsend
import { Unsend } from "unsend";
const client = new Unsend({ apiKey: process.env.UNSEND_API_KEY,});
await client.emails.send({ to: "user@example.com", from: "no-reply@yourdomain.com", subject: "Test", text: "Hello",});After useSend
# install packagenpm i usesend-js import { UseSend } from "usesend";
const client = new UseSend({ apiKey: process.env.USESEND_API_KEY,});
await client.emails.send({ to: "user@example.com", from: "no-reply@yourdomain.com", subject: "Test", text: "Hello",});
Rubix Studios previously published the PayloadCMS email integration article and initial Unsend adapter. That integration remains functionally valid because payload shapes are unchanged. Rubix Studios has published an updated PayloadCMS adapter that references the useSend package and endpoints to preserve continuity for PayloadCMS implementers.
See the original integration for background and implementation patterns at PayloadCMS Email Integration.
The useSend rebrand replaces Unsend at domain and SDK level while preserving payload compatibility. The work required for migration is focused on dependency, import, and endpoint updates followed by validation testing. Rubix Studios has updated PayloadCMS resources to support this transition and can assist with implementation and verification.