Integre seu app
Cadastro vira contato, eventos viram automações e os e-mails de login saem pela Postal: ligue a cobrança e o login do seu app sem código novo no backend.
#Visão geral
O ciclo de vida do usuário do seu produto passa por três momentos em que a Postal entra sem código novo no seu backend:
- Cadastro vira contato. Quando alguém se cadastra no seu app (Supabase, Clerk, Auth0, Firebase) ou vira cliente no Stripe, a Postal cria o contato com o e-mail, o nome e o ID do usuário no seu app (
external_id). - Eventos viram automações. Pagamento aprovado, falha de cobrança, teste acabando, cancelamento, login: cada um fica registrado no contato como evento e pode iniciar uma automação.
- E-mails de login saem pela Postal. Confirmação de cadastro, link mágico, redefinição de senha e convites saem do seu domínio, com os seus modelos, pela mesma API dos e-mails transacionais.
#Escolha a sua integração
- StripeClientes, assinaturas, faturas, checkout e contestações.
- SupabaseUsuários do Supabase Auth e o Send Email Hook para os e-mails de login.
- ClerkUsuários, lista de espera e logins, com assinatura Svix.
- Auth0Cadastros, logins e exclusões por Log Stream, e o provedor de e-mail por Actions.
- Firebase AuthDuas Cloud Functions avisam a Postal de cada usuário criado ou excluído.
- Better AuthVerificação, redefinição de senha e magic link pela API.
- Auth.js (NextAuth)O provedor de e-mail (magic link) enviando pela API.
#Cadastro vira contato
Em Integrações › Seu app, conecte a fonte e cole a URL da conexão no provedor. Cada usuário é casado pelo ID dele no seu app (external_id), então uma troca de e-mail atualiza o mesmo contato. No Stripe, o cliente é casado pelo e-mail e ligado ao ID do Stripe (cus_…), e o metadata.user_id do cliente, se existir, vira o external_id.
Se o seu app já manda eventos para a Postal pela API, use o mesmo ID do usuário em external_id (ou user_id) nas chamadas de contatos e eventos: as integrações e o seu código passam a falar do mesmo contato.
#Eventos viram automações
Os eventos das integrações têm nomes estáveis, no formato <fonte>.<tipo>:
| Fonte | Exemplos de eventos |
|---|---|
| Stripe | stripe.invoice.paid, stripe.invoice.payment_failed, stripe.customer.subscription.trial_will_end, stripe.customer.subscription.deleted |
| Supabase | supabase.user.created, supabase.user.confirmed, supabase.user.deleted |
| Clerk | clerk.user.created, clerk.waitlistEntry.created, clerk.session.created |
| Auth0 | auth0.user.signed_up, auth0.user.logged_in, auth0.user.deleted |
| Firebase Auth | firebase.user.created, firebase.user.deleted |
Crie a automação com o gatilho Evento recebido e o nome do evento, ou clique em Criar automação ao lado do evento na tela da conexão. Algumas ideias:
- Boas-vindas:
supabase.user.created→ e-mail de boas-vindas, espera de 2 dias, dicas de uso. - Cobrança recusada:
stripe.invoice.payment_failed→ e-mail com o link da fatura ({{event.hosted_invoice_url}}). - Fim do teste:
stripe.customer.subscription.trial_will_end→ lembrete com o plano ({{event.plan}}). - Cancelamento:
stripe.customer.subscription.deleted→ pesquisa de saída e tag “ex-cliente”.
Eventos que o seu produto conhece e o provedor não (um projeto criado, um limite atingido) vão pelo POST /events com o mesmo contato. Para isso, há SDKs e uma CLI: veja SDKs e CLI.
#E-mails de login pela Postal
| Biblioteca | Como |
|---|---|
| Supabase | Send Email Hook apontado para a Postal: sem código, com um modelo por tipo de e-mail, editável no painel. |
| Better Auth | sendVerificationEmail, sendResetPassword e o plugin de magic link chamando POST /emails. |
| Auth.js | Um provedor de e-mail com sendVerificationRequest chamando POST /emails. |
| Auth0 | Provedor de e-mail customizado por Actions chamando POST /emails. |
| Clerk e Firebase | Use o SMTP da Postal nas configurações de e-mail do provedor, quando ele aceitar SMTP próprio. |
Os e-mails de login saem de um domínio verificado do seu time e contam nas mesmas cotas de envio dos e-mails da API.