Skip to main content

​
Em uma frase

Quando algo importante acontece no seu sistema (conta criada, pedido pago, integração concluída), você avisa o Notifique uma vez; o Notifique executa a jornada que você montou — envios, esperas, atualização de contato, ramificações — sem você ter que refazer fila, retry e acompanhamento na mão.

​
Três ideias simples

Pense em três “camadas” que conversam entre si:
  1. Evento — o nome do fato (user.signed_up, order.paid…) e, se quiser, um schema opcional: lista de campos esperados no payload (texto, número ou sim/não) para o disparo não ir com dados errados.
  2. Automação — o roteiro: começa no mesmo nome de evento, depois vem os passos (mensagens, espera, condição “se / senão”, atualizar contato…). Pode estar ligada ou pausada (ENABLED / DISABLED).
  3. Run — cada vez que você dispara o evento para alguém, nasce uma execução daquela automação: dá para ver o que já rodou, o que falhou e quando — útil para suporte e auditoria.

​
Exemplos do dia a dia

  • Onboarding — “Assim que a pessoa se cadastra, manda e-mail de boas-vindas; três dias depois, manda outro com dicas.” → um evento + uma automação com espera entre os dois envios.
  • Plano gratuito vs pago — “Se o payload diz que o plano é free, manda um tipo de mensagem; se é pago, manda outro.” → mesma automação com condição em cima dos dados do evento ou do contato (o fluxo completo você pode montar no painel; pela API o grafo segue as mesmas regras).
  • Não apressar a jornada — “Só manda o próximo e-mail depois que a integração foi concluída.” → o seu backend só chama POST /v1/events/send do passo seguinte quando fizer sentido, ou você encaixa delays e condições no grafo.

​
Painel e API v1

  • Painel — editor visual de automações (mesmo conceito de grafo).
  • API — https://api.notifique.dev/v1 com Authorization: Bearer sk_... ou x-api-key: cadastro de eventos, disparo (POST /v1/events/send), CRUD de automações e leitura de runs.
Ou seja: quem prefere clicar e quem prefere integrar por código usam o mesmo motor.

​
O disparo que liga tudo

O caminho mais comum é POST /v1/events/send: você manda o nome do evento, quem é o destinatário (contato, e-mail ou telefone) e o payload. O servidor valida o schema (se existir), encontra o contato e cria uma run por automação habilitada que escuta aquele nome de evento.

​
Destinatário e “várias automações ao mesmo tempo”

  • Informe apenas um entre contactId, email ou phone (telefone no formato E.164). O workspace precisa chegar a um contato claro; senão a API responde 404 ou 409, conforme o caso.
  • Se várias automações ENABLED usam o mesmo evento no gatilho, um disparo pode gerar várias runs — cada roteiro segue o seu. Vale planejar volume e custo dos canais (envios seguem as mesmas bases de cobrança/limite que você já usa em campanhas e envios avulsos).

​
Idempotência (evitar duplicar por engano)

Header opcional Idempotency-Key em POST /v1/events/send. Se a sua aplicação reenviar a mesma requisição (timeout, retry), a mesma chave no mesmo workspace tende a devolver o mesmo resultado (idempotentReplay quando aplicável), em vez de criar jornadas duplicadas.

​
Pausar de verdade

POST /v1/automations/:id/stop desliga a automação e tenta cancelar o que ainda não rodou (abordagem best-effort). Runs já concluídas continuam no histórico. Pode haver uma janela pequena entre workers — use como regra de produto, não como relógio atômico ao milissegundo.

​
Escopos de API Key (resumo)

  • events:read / events:write — eventos + POST /v1/events/send.
  • automations:read / automations:write — automações, stop, listagem e detalhe de runs.