Say that adding the suppression events back with PATCH sends the full events list

apps/docs/content/docs/migrate-from-resend.mdx

@@ -102,7 +102,7 @@ Three things shorten it:
 | Contacts | Email, names, `unsubscribed`, properties, topic subscriptions, segment memberships. Opt-outs are preserved; nobody is re-subscribed. |
 | Segments, topics, properties | Matched by name / name / key: created when missing, updated when different. |
 | Templates | Name, alias, subject, html, text. `from`, `reply_to` and `variables` cannot be stored — listed as manual steps. |
-| Webhooks | Endpoint and events. The signing secret is copied, so the receiver you already run keeps verifying (deliveries carry the `svix-*` headers). `--fresh-webhook-secrets` mints new ones. Events MillionSend also emits carry over — all eleven `email.*` types, `contact.created`, `contact.updated` and `contact.deleted`, `suppression.added` and `suppression.removed`, and the twelve `inbox.*` types MillionSend sends; the rest (`contact.topics.updated`, `domain.*`, `topic.*`, `inbox.thread.assigned`, `inbox.thread.unassigned`) are dropped per webhook and listed. `email.scheduled`, `email.failed` and `email.suppressed` carry over only to an instance that emits them (its `GET /openapi.json` lists them). An older one refuses those webhooks with a 422: migrate to it with `npx @millionsend/cli@0.2.3`, which drops the three along with `suppression.added` and `suppression.removed` and lists all five; add those two back to the webhook afterwards, in the dashboard or with `PATCH /webhooks/{id}`. |
+| Webhooks | Endpoint and events. The signing secret is copied, so the receiver you already run keeps verifying (deliveries carry the `svix-*` headers). `--fresh-webhook-secrets` mints new ones. Events MillionSend also emits carry over — all eleven `email.*` types, `contact.created`, `contact.updated` and `contact.deleted`, `suppression.added` and `suppression.removed`, and the twelve `inbox.*` types MillionSend sends; the rest (`contact.topics.updated`, `domain.*`, `topic.*`, `inbox.thread.assigned`, `inbox.thread.unassigned`) are dropped per webhook and listed. `email.scheduled`, `email.failed` and `email.suppressed` carry over only to an instance that emits them (its `GET /openapi.json` lists them). An older one refuses those webhooks with a 422: migrate to it with `npx @millionsend/cli@0.2.3`, which drops the three along with `suppression.added` and `suppression.removed` and lists all five; add those two back to the webhook afterwards, in the dashboard or with `PATCH /webhooks/{id}` sending its full `events` list (PATCH replaces the list). |
 | Suppressions | Bounces, complaints and manual entries, with their origin. |
 | Domains | Created with return path and tracking settings, in the one SES region your MillionSend instance serves (MillionSend Cloud: `sa-east-1`) — the Resend region does not carry over. On MillionSend Cloud, tracking toggles only carry over together with a tracking subdomain; without one the report lists them for you to set up in the dashboard. DNS records must be added again — see step 3. |
 | Broadcasts | Drafts and scheduled ones import as drafts. Sent ones are skipped unless `--include-sent`. |

apps/docs/content/docs/migrate-from-resend.pt-BR.mdx

@@ -105,7 +105,7 @@ Três coisas encurtam isso:
 | Contatos | E-mail, nomes, `unsubscribed`, propriedades, inscrições em tópicos, associações a segmentos. Descadastros são preservados; ninguém é reinscrito. |
 | Segmentos, tópicos, propriedades | Casados por nome / nome / chave: criados quando faltam, atualizados quando diferem. |
 | Templates | Nome, alias, assunto, html, texto. `from`, `reply_to` e `variables` não podem ser armazenados — listados como passos manuais. |
-| Webhooks | Endpoint e eventos. O segredo de assinatura é copiado, então o receptor que você já roda continua verificando (as entregas carregam os headers `svix-*`). `--fresh-webhook-secrets` gera segredos novos. Eventos que o MillionSend também emite são levados junto — todos os onze tipos `email.*`, `contact.created`, `contact.updated` e `contact.deleted`, `suppression.added` e `suppression.removed`, e os doze tipos `inbox.*` que o MillionSend envia; os demais (`contact.topics.updated`, `domain.*`, `topic.*`, `inbox.thread.assigned`, `inbox.thread.unassigned`) são descartados por webhook e listados. `email.scheduled`, `email.failed` e `email.suppressed` só são levados para uma instância que emite esses eventos (o `GET /openapi.json` dela lista os três). Uma instância mais antiga recusa esses webhooks com 422: para migrar para ela, use `npx @millionsend/cli@0.2.3`, que descarta os três junto com `suppression.added` e `suppression.removed` e lista os cinco; depois, adicione os dois de novo ao webhook, pelo painel ou com `PATCH /webhooks/{id}`. |
+| Webhooks | Endpoint e eventos. O segredo de assinatura é copiado, então o receptor que você já roda continua verificando (as entregas carregam os headers `svix-*`). `--fresh-webhook-secrets` gera segredos novos. Eventos que o MillionSend também emite são levados junto — todos os onze tipos `email.*`, `contact.created`, `contact.updated` e `contact.deleted`, `suppression.added` e `suppression.removed`, e os doze tipos `inbox.*` que o MillionSend envia; os demais (`contact.topics.updated`, `domain.*`, `topic.*`, `inbox.thread.assigned`, `inbox.thread.unassigned`) são descartados por webhook e listados. `email.scheduled`, `email.failed` e `email.suppressed` só são levados para uma instância que emite esses eventos (o `GET /openapi.json` dela lista os três). Uma instância mais antiga recusa esses webhooks com 422: para migrar para ela, use `npx @millionsend/cli@0.2.3`, que descarta os três junto com `suppression.added` e `suppression.removed` e lista os cinco; depois, adicione os dois de novo ao webhook, pelo painel ou com `PATCH /webhooks/{id}` enviando a lista `events` completa (o PATCH substitui a lista). |
 | Supressões | Bounces, reclamações e entradas manuais, com sua origem. |
 | Domínios | Criados com return path e configurações de rastreamento, na única região do SES atendida pela sua instância do MillionSend (MillionSend Cloud: `sa-east-1`) — a região do Resend não é levada junto. No MillionSend Cloud, as opções de rastreamento só vêm junto com um subdomínio de rastreamento; sem ele, o relatório as lista para você configurar no painel. Os registros DNS precisam ser adicionados de novo — veja o passo 3. |
 | Transmissões | Rascunhos e transmissões agendadas entram como rascunhos. As já enviadas são puladas, a menos que `--include-sent`. |

packages/cli/README.md

@@ -23,7 +23,7 @@ Node 18 or newer; no dependencies.
 | Contacts | Upserted by email through the batch endpoint; `unsubscribed` and topic opt-outs are preserved, never re-subscribed. Topic subscriptions and properties follow in two per-contact passes that run after everything else, so the account is sendable before they finish. |
 | Segments, topics, properties | Matched by name / name / key: created when missing, updated when different, left alone when equal. Segment memberships follow the contacts. |
 | Templates | Name, alias, subject, html, text. From, reply-to and variables cannot be stored — listed as manual steps. |
-| Webhooks | Endpoint and events. Signing secrets are copied so receivers keep verifying (`--fresh-webhook-secrets` mints new ones, shown once). Events MillionSend also emits carry over (`email.*`, `contact.created`, `contact.updated`, `contact.deleted`, `suppression.added`, `suppression.removed`, and `inbox.*` except `inbox.thread.assigned` and `inbox.thread.unassigned`); the rest are dropped per webhook and listed. `email.scheduled`, `email.failed` and `email.suppressed` carry over only to an instance that emits them (its `GET /openapi.json` lists them). An older one refuses those webhooks with a 422: migrate to it with `npx @millionsend/cli@0.2.3`, which drops the three along with `suppression.added` and `suppression.removed` and lists all five; add those two back to the webhook afterwards, in the dashboard or with `PATCH /webhooks/{id}`. |
+| Webhooks | Endpoint and events. Signing secrets are copied so receivers keep verifying (`--fresh-webhook-secrets` mints new ones, shown once). Events MillionSend also emits carry over (`email.*`, `contact.created`, `contact.updated`, `contact.deleted`, `suppression.added`, `suppression.removed`, and `inbox.*` except `inbox.thread.assigned` and `inbox.thread.unassigned`); the rest are dropped per webhook and listed. `email.scheduled`, `email.failed` and `email.suppressed` carry over only to an instance that emits them (its `GET /openapi.json` lists them). An older one refuses those webhooks with a 422: migrate to it with `npx @millionsend/cli@0.2.3`, which drops the three along with `suppression.added` and `suppression.removed` and lists all five; add those two back to the webhook afterwards, in the dashboard or with `PATCH /webhooks/{id}` sending its full `events` list (PATCH replaces the list). |
 | Suppressions | Bounces, complaints and manual entries, with their origin. |
 | Domains | Created with return path and tracking settings, in the one SES region your MillionSend instance serves (MillionSend Cloud: `sa-east-1`) — the Resend region does not carry over. DNS records must be added again (DKIM keys are per provider); the report prints a copy-ready table. Both providers can stay verified side by side. |
 | Broadcasts | Drafts and scheduled ones import as drafts; sent ones are skipped unless `--include-sent`. |