Pular para o conteúdo principal
NexxiSend
Developer API

Uma referência única para todos os canais

A NexxiSend nasce como API: o console é apenas um cliente dela. Esta página descreve o contrato planejado da Universal Messaging API. Os endpoints ainda não estão públicos — nenhuma chave é emitida nesta etapa.

Pedir acesso à API Entrar no console

Quickstart

  1. 1Crie um workspace e gere uma API key com escopo restrito.
  2. 2Envie a primeira mensagem no sandbox, sem custo e sem envio real.
  3. 3Assine os webhooks de status e reconcilie custo por tentativa.
  4. 4Ative providers reais quando as credenciais estiverem no vault.

Autenticação

Bearer token por workspace, com escopos por recurso. Chaves de provider ficam no backend, nunca no cliente.

Authorization: Bearer nxs_live_•••••••
exemplo
curl -X POST https://api.nexxisend.com/v1/messages \
  -H "Authorization: Bearer $NEXXI_API_KEY" \
  -H "Idempotency-Key: ord_92f4c1" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+5511999999999",
    "content": { "text": "Seu código é 481920" },
    "channels": ["whatsapp", "sms"],
    "routing": { "strategy": "lowest_effective_cost" },
    "fallback": { "enabled": true, "window_seconds": 60 }
  }'

Resposta 202

{
  "id": "msg_01HTX9",
  "status": "routed",
  "channel": "whatsapp",
  "provider": "meta_cloud_api",
  "attempts": 1,
  "cost_estimate": 0.0089,
  "currency": "BRL",
  "fallback_chain": ["whatsapp", "sms"],
  "created_at": "2026-03-14T18:22:41Z"
}
Referência

Endpoints planejados

Recursos previsíveis, erros tipados, paginação por cursor e idempotência por chave em toda operação de escrita.

  • POST/v1/messagesEnvio omnichannel com roteamento e fallback.
  • GET/v1/messages/{id}Estado atual, tentativas, provider e custo.
  • GET/v1/messages/{id}/eventsTimeline completa de eventos da mensagem.
  • POST/v1/contactsContatos com consentimento e opt-out.
  • GET/v1/routes/simulateSimula a decisão do NexxiRoute AI sem enviar.
  • GET/v1/finops/usageCusto, receita e margem por período.
  • POST/v1/webhooksRegistro de endpoints e eventos assinados.

Webhooks

Eventos assinados com HMAC, reentrega com backoff e ordem por mensagem. Cada payload carrega provider, tentativa, custo e motivo de falha — base do FinOps e do audit trail.

  • message.queued

    Aceita e enfileirada; idempotência já resolvida.

  • message.routed

    Canal e provider escolhidos, com motivo da decisão.

  • attempt.failed

    Tentativa falhou; fallback avaliado.

  • message.delivered

    Entrega confirmada pelo provider.

  • message.read

    Leitura, quando o canal reporta.

  • contact.opted_out

    Opt-out registrado e supressão aplicada.

Idempotência

Reenvie a mesma requisição com a mesma Idempotency-Key sem risco de duplicar envio ou cobrança. O fallback nunca reentrega uma mensagem já confirmada como entregue.

Erros tipados

  • 401invalid_api_keyChave ausente, revogada ou de outro workspace.
  • 403permission_deniedToken sem escopo para o recurso ou tenant.
  • 409idempotency_conflictMesma Idempotency-Key com payload diferente.
  • 422no_route_availableNenhuma rota elegível para o destino e política.
  • 429rate_limitedLimite do workspace excedido; use Retry-After.
  • 503provider_unavailableProviders indisponíveis após fallback.

Boas práticas

  • Valide a assinatura antes de processar o payload.
  • Responda 2xx rápido e processe de forma assíncrona.
  • Trate eventos como at-least-once e deduplique por event id.
  • Nunca exponha API keys no frontend.

SDKs e sandbox

SDKs para Node, Python, PHP e Go estão planejados sobre a mesma Universal Messaging API, junto de um sandbox com providers simulados. Status atual: em construção — nada aqui simula uma integração já ativa.

Entrar na lista