feat(inboxes): accept path attachments on drafts

Merged
DI
7h ago
+128-7

resend.inboxes.drafts.create() and .update() now accept path attachments. The API change is live (resend/resend-monorepo#13475), and the spec is in resend/resend-openapi#141.

Changes

InboxDraftAttachmentOptions is now a union, so invalid shapes don't compile:

| { content: string | Buffer; path?: never; filename: string; contentType: string }
| { path: string; content?: never; filename: string; contentType?: string } // contentType defaults to the downloaded file's type

parseAttachments already maps path, so no runtime change was needed. The create/update doc comments now describe the path rules.

The exported name is unchanged, but it's now a type alias instead of an interface. Code that does interface X extends InboxDraftAttachmentOptions would stop compiling. I don't expect anyone to do that with a request options type.

Version: 6.35.0 → 6.36.0 (minor). The CLI and OSS MCP will pin 6.36.0.

Verification

  • pnpm lint, pnpm typecheck, pnpm test and pnpm build all pass.
  • New tests: create and update send path without content. A compile-time test rejects an attachment with no source, with both sources, or with content and no contentType.
  • Live against api.resend.com, using the built dist:
    • create with path stores invoice.pdf (application/pdf, 80893 bytes)
    • update with path + content stores both
    • an ftp:// path returns 422
    • send succeeds

Linear: DEV-2419

Summary by cubic

resend.inboxes.drafts.create() and .update() now accept path attachments, so drafts can reference a URL that the API downloads and stores instead of requiring inline content. This unlocks path attachment support for the CLI and MCP.

InboxDraftAttachmentOptions is now a union, so invalid shapes fail at compile time: each attachment needs either content with a contentType, or a path URL. The exported name is unchanged, but the type is now a type alias instead of an interface, which would break code that extends it. Version bumped to 6.36.0.