Skip to content

feat: Resend transactional email integration (RESEND toolpack) - #570

Open
dilandia wants to merge 1 commit into
fazer-ai:mainfrom
dilandia:feat/resend-toolpack
Open

feat: Resend transactional email integration (RESEND toolpack)#570
dilandia wants to merge 1 commit into
fazer-ai:mainfrom
dilandia:feat/resend-toolpack

Conversation

@dilandia

@dilandia dilandia commented Sep 7, 2026

Copy link
Copy Markdown

O que este PR adiciona

Integração nativa de e-mail transacional via Resend no catálogo de integrações, no mesmo molde do toolpack Asaas:

  • Entrada RESEND no catálogo (kind TOOLPACK)
  • email_send — envia e-mail ao cliente (confirmação de agendamento, lembrete, follow-up). Invariantes de segurança espelhando o spec do Asaas: from/reply_to presos à config da instância (nunca args do modelo — prompt-injection não troca o remetente do domínio verificado do tenant); a API key flui só pro header via vault; origem fixa; https-only, sem redirects, timeout e leitura limitados. Grava IntegrationExternalRef (kind resend_email) para correlação futura de webhooks de entrega por PK.
  • email_status — projeção limitada de GET /emails/{id} (só campos de status; nunca o HTML de volta ao contexto). HTTP 403 no envio vira a dica acionável de domínio não verificado.
  • Secret type resend no vault — bearer, probe de conectividade em /domains, aceitando restricted_api_key (key sending-only) como válida.
  • Console — labels do catálogo, seção de config (remetente/reply-to com hint de domínio verificado), metadata das tools, marca do Resend (simple-icons, CC0), locales pt-BR/en.
  • Testestests/modules/toolpacks-resend.test.ts (allowlist fail-closed, sender preso à config, fail-closed sem credencial/from, projeção de status) + linha na tabela de decisão do secret-type-fit + entradas justificadas no ledger de i18n idênticas-por-design (marca própria, com bump do pino documentado).

Fora de escopo (de propósito)

Webhooks inbound de entrega (delivered/bounced): o Resend assina com Svix, que a estratégia HMAC_SHA256 genérica não verifica. Fica para um follow-up com verificador Svix-aware, para o qual o IntegrationExternalRef já gravado aqui é o pré-requisito.

Nota

Inclui uma normalização de separadores de path no sweep do error-catalog para que as isenções por literal de caminho valham em checkouts Windows. Feliz em separar em PR próprio se preferirem.

bun check verde (10.444 pass / 0 fail, com banco).

🤖 Generated with Claude Code

https://claude.ai/code/session_01CzKQNp9oM3hgBBQPrrictx

Adds a RESEND catalog entry (TOOLPACK) with two outbound tools, mirroring
the Asaas hardened spec: email_send (from/reply_to bound to the instance
config, never model args; correlation ref recorded for future inbound
delivery webhooks) and email_status (bounded projection of GET /emails/:id).
Ships the resend vault secret type (bearer, /domains connectivity probe
accepting restricted keys), the console wiring (catalog labels, config
section for sender/reply-to, tool metadata, brand mark) and pt-BR/en locales.

Inbound delivery events are left out on purpose: Resend signs webhooks with
Svix, which the generic HMAC strategy does not verify.

Also normalizes path separators in the error-catalog sweep so its
path-literal exemptions hold on Windows checkouts.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CzKQNp9oM3hgBBQPrrictx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant