The gap
The /api/compat/* endpoints — drop-in shims for resend, sendgrid, postmark, mailgun and plunk — are the headline migration feature, with five vendor pages behind them. They appear in zero of the 57 paths in https://api.sendly.now/api/openapi.json (checked 2026-09-03).
Because the SDK's types are generated from that spec, the compat surface is invisible here too: no types, no client methods, nothing an editor can autocomplete. Any spec-driven consumer — codegen, an agent, a generated client in another language — cannot discover the feature at all. It exists only in prose on the docs site, which (see the discoverability issue) is itself 403 to non-browser fetchers.
Suggested fix
Add the compat paths to the OpenAPI document. They are real HTTP endpoints with real request shapes; there is no reason for them to be spec-invisible. Once they are in the spec, this SDK gets them for free on the next regeneration.
Adjacent: a useSend compat endpoint would be close to free
There is no /api/compat/usesend. useSend's wire shape is essentially Resend's, which is already implemented — so the delta over the existing resend shim is small.
It is also the migration most likely to be attempted, and the most dangerous one to attempt naively: Sendly's send endpoint and auth header are identical to useSend's, but the content field is body rather than html, so "just change the base URL" authenticates successfully and sends an empty email. A compat endpoint would make that migration exactly as safe as it already looks. (We hit this migrating a production app off useSend; we are unlikely to be the last, given the overlap in who uses it.)
Context
Found while migrating a production app onto Sendly. Verified 2026-09-03.
The gap
The
/api/compat/*endpoints — drop-in shims for resend, sendgrid, postmark, mailgun and plunk — are the headline migration feature, with five vendor pages behind them. They appear in zero of the 57 paths inhttps://api.sendly.now/api/openapi.json(checked 2026-09-03).Because the SDK's types are generated from that spec, the compat surface is invisible here too: no types, no client methods, nothing an editor can autocomplete. Any spec-driven consumer — codegen, an agent, a generated client in another language — cannot discover the feature at all. It exists only in prose on the docs site, which (see the discoverability issue) is itself 403 to non-browser fetchers.
Suggested fix
Add the compat paths to the OpenAPI document. They are real HTTP endpoints with real request shapes; there is no reason for them to be spec-invisible. Once they are in the spec, this SDK gets them for free on the next regeneration.
Adjacent: a useSend compat endpoint would be close to free
There is no
/api/compat/usesend. useSend's wire shape is essentially Resend's, which is already implemented — so the delta over the existing resend shim is small.It is also the migration most likely to be attempted, and the most dangerous one to attempt naively: Sendly's send endpoint and auth header are identical to useSend's, but the content field is
bodyrather thanhtml, so "just change the base URL" authenticates successfully and sends an empty email. A compat endpoint would make that migration exactly as safe as it already looks. (We hit this migrating a production app off useSend; we are unlikely to be the last, given the overlap in who uses it.)Context
Found while migrating a production app onto Sendly. Verified 2026-09-03.