Migrar da Take Blip

​

Quando faz sentido migrar

• Você usa a Blip principalmente pela API, e pouco do Builder.
• Quer operar pelo terminal (CLI) ou por agentes de IA como Claude e Cursor (MCP server).
• Quer SDKs e documentação que refletem a API real.
• Quer o Brain, com actions integradas, na mesma plataforma.

​

Quando não migrar

• Você tem muitos fluxos visuais no Blip Builder em produção. Recriar fluxos é trabalho real.
• Você precisa de vários canais além de WhatsApp. A Arara é focada em WhatsApp.
• Você depende de um contrato ou SLA específico da Blip.

​

Comparativo

​

O processo de migração

​

Fase 1: preparação

1. Liste os templates aprovados que você usa na Blip (nome, categoria, idioma, texto).
2. Liste os números em uso.
3. Liste as integrações com a API da Blip e os fluxos do Builder.
4. Crie a organização em https://app.ararahq.com e gere uma chave de API.

​

Fase 2: número

5. Conecte o número na Arara pelo dashboard, em Números. Se o número está hoje em uma WABA gerida pela Blip, a liberação segue o processo de troca de provedor da Meta.
6. Durante a troca, mantenha a Blip ativa até o número estar conectado na Arara.

​

Fase 3: templates

7. Confira no dashboard ou em GET /v1/templates quais templates estão disponíveis na organização. Os que faltarem, recrie:

curl -X POST https://api.ararahq.com/v1/templates \
  -H "Authorization: Bearer $ARARA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "pedido_confirmado",
    "category": "UTILITY",
    "language": "pt_BR",
    "body": "Oi {{1}}, seu pedido {{2}} foi confirmado.",
    "samples": { "1": "João", "2": "ARA-123" }
  }'

​

Fase 4: diff de código

import axios from 'axios';

await axios.post(
  'https://msging.net/messages',
  {
    to: '5511999999999@wa.gw.msging.net',
    type: 'application/json',
    content: {
      type: 'template',
      template: {
        namespace: 'abc-def-123',
        name: 'pedido_confirmado',
        language: { code: 'pt_BR' },
        components: [
          {
            type: 'body',
            parameters: [
              { type: 'text', text: 'João' },
              { type: 'text', text: 'ARA-123' },
            ],
          },
        ],
      },
    },
  },
  {
    headers: {
      'Authorization': `Key ${BLIP_KEY}`,
      'Content-Type': 'application/json',
    },
  }
);

import { NodeSDK } from '@ararahq/sdk';

const sdk = new NodeSDK({ apiKey: process.env.ARARA_API_KEY! });

await sdk.messages.send(
  {
    receiver: '+5511999999999',
    templateName: 'pedido_confirmado',
    templateVariables: ['João', 'ARA-123'],
  },
  { idempotencyKey: 'pedido-ARA-123-confirmado' },
);

• Sem identificador de gateway (@wa.gw.msging.net): o destinatário vai como +<DDI><número>.
• Sem namespace: o template é identificado pelo nome.
• Sem components: variáveis em array posicional. Se o template tem header de mídia, a URL vai na primeira posição.

​

Fase 5: webhooks

app.post('/blip/webhook', (req, res) => {
  const { type, content, from } = req.body;
  if (type === 'text/plain') {
    const phone = from.replace('@wa.gw.msging.net', '');
    const text = content;
  }
  res.send('OK');
});

// Valide X-Arara-Signature com o corpo cru antes de parsear (veja /webhooks).
app.post('/arara/webhook', express.text({ type: 'application/json' }), (req, res) => {
  if (!isValidAraraSignature(req)) return res.status(401).end();

  const { event, data } = JSON.parse(req.body);
  if (event === 'message.received') {
    const phone = data.from; // só dígitos, ex.: 5511999999999
    const text = data.body;
  }
  res.status(204).end();
});

• É um só por organização, para todos os eventos (message.received, message.status_updated, template.updated, campaign.completed e outros).
• Vem assinado: X-Arara-Signature = sha256= + HMAC-SHA256 de {X-Arara-Timestamp}.{corpo cru} com o secret da organização.
• Usa o envelope { event, apiVersion, data, timestamp, organizationId }.

​

Fase 6: fluxos do Blip Builder

• Gatilho no message.received.
• Decisão por palavra-chave ou regra.
• Resposta com POST /v1/messages dentro da janela de 24h.

• Base de conhecimento (texto, URL ou PDF).
• Actions como cobrança Pix, link de pagamento, agendamento e encaminhamento para humano.
• Handoff para o time com o evento conversation.needs_human.

• Gatilhos como carrinho abandonado, pagamento recusado, etiqueta aplicada ou primeira mensagem.
• Passos de mensagem (template), espera, condição e etiqueta, montados no dashboard.

​

Cutover

1. Número conectado e templates aprovados na Arara.
2. Webhook configurado e validado.
3. Deploy do código adaptado, com a Blip ainda disponível para rollback.
4. Acompanhamento no dashboard nos primeiros dias.
5. Encerramento na Blip depois de validado.

​

Próximos passos