Operações chave-valor no Redis — GET, SET, DEL e listagem de chaves.
Nó Redis
O nó de workflow Redis (redis_request) executa operações de cache chave-valor no Redis por meio de um proxy HTTP seguro. Assim como o nó Postgres, a WhatsWave não abre conexão TCP direta com o Redis — você opera uma API pequena que traduz comandos JSON em chamadas Redis.
ID do nó no editor: redis_request
Variável de URL padrão: {{redis_api_url}}
Auth: Bearer {{redis_api_token}}
O que faz
A cada execução, o engine:
- Resolve variáveis em URL, headers e body
- Envia um
POSTcom payload JSON de comando ao seu proxy Redis - Retorna status, data e headers
| Propriedade | Valor |
|---|---|
| Rótulo na paleta | Redis |
| Executor | http_request |
| Método padrão | POST |
| Timeout da requisição | 30 segundos |
Pré-requisitos
- Uma instância Redis (self-hosted, Redis Cloud, ElastiCache, etc.)
- Um proxy HTTP que aceita comandos JSON e retorna resultados JSON
- Chaves de integração:
redis_api_url— endpoint do proxy (ex.:https://your-service.com/redis)redis_api_token— bearer token validado pelo proxy
Adicione as chaves em Configurações → Chaves de API → Chaves de integração.
Como configurar
Passo 1 — Adicionar o nó
- Abra Automações
- Paleta → Dados → Redis
- Conecte após o gatilho ou nós de lógica
Passo 2 — Templates de operação
| Template | Body | Finalidade |
|---|---|---|
| GET | {"command": "GET", "key": "mykey"} | Ler um valor string |
| SET | {"command": "SET", "key": "mykey", "value": "myvalue"} | Gravar um valor string |
| DEL | {"command": "DEL", "key": "mykey"} | Excluir uma chave |
| LIST keys | {"command": "KEYS", "pattern": "*"} | Listar chaves que correspondem ao padrão |
Estenda o body para outros comandos que seu proxy suporte (EXPIRE, INCR, HGET, LPUSH, etc.).
Passo 3 — Configurar campos
| Campo | Obrigatório | Descrição |
|---|---|---|
| URL / Endpoint | Sim | {{redis_api_url}} |
| Method | Sim | Geralmente POST |
| Headers (JSON) | Sim | Authorization + Content-Type: application/json |
| Body (JSON) | Sim | Objeto de comando (veja os templates) |
Exemplo — cache de resposta de API com TTL (se o proxy suportar EXPIRE):
Passo 1 — SET:
{
"command": "SET",
"key": "customer:{{trigger.body.phone}}",
"value": "{{variables.customer_json}}"
}
Passo 2 — nó separado ou proxy combinado:
{
"command": "EXPIRE",
"key": "customer:{{trigger.body.phone}}",
"seconds": 3600
}
Exemplo — chave de deduplicação:
{
"command": "SET",
"key": "webhook:{{trigger.body.event_id}}",
"value": "1",
"nx": true
}
(Seu proxy pode mapear nx para Redis SET NX.)
Passo 4 — Usar a saída
{{redis_1.data}}
{{redis_1.status}}
Interprete data conforme o formato de resposta do seu proxy (ex.: { "value": "..." } para GET).
Saídas do nó
| Campo de saída | Descrição |
|---|---|
status | Status HTTP do proxy |
data | Resultado do comando (value, OK, contagem de chaves, etc.) |
headers | Headers de resposta |
Contrato da API do proxy
Seu proxy deve aceitar:
{
"command": "GET",
"key": "session:abc123"
}
E retornar algo utilizável downstream:
{
"value": "{"name":"João"}",
"found": true
}
Requisitos de segurança:
- Autenticar toda requisição com o bearer token
- Bloquear comandos perigosos em produção (
FLUSHALL,KEYS *em instâncias grandes,CONFIG) - Preferir SCAN em vez de KEYS para listagem em proxies de produção
- Namespaces de chaves por company ou workflow (
whatswave:{company_id}:{key}) - Usar TLS no endpoint do proxy
Dicas e boas práticas
- Use Redis para cache e dedup, não como banco primário — Postgres/Supabase mantêm a source of truth
- Defina TTLs em chaves de cache para evitar dados obsoletos e crescimento de memória
- Convenção de nomes de chave —
entity:id:field(ex.:order:550e8400:status) - **Evite KEYS *** em produção — implemente SCAN no seu proxy para listagem por padrão
- Serialize JSON como strings no SET; faça parse no nó JavaScript no GET
- Combine GET → Condição → SET para padrões read-through cache
- A infraestrutura da WhatsWave usa Redis para filas — seu nó fala com seu Redis via proxy, não com o cache interno da WhatsWave
Exemplos de casos de uso
Idempotência de webhook
- Gatilho Webhook
- Redis GET —
webhook:{{trigger.body.id}} - Condição — já processado → Return antecipado
- Processar evento → Redis SET com event ID
Cache de API externa cara
- Redis GET —
product:{{variables.sku}} - Condição — cache hit → pular nó HTTP
- HTTP — buscar produto → Redis SET com TTL de 1 hora
Contador de rate-limit (com suporte a INCR no proxy)
- Gatilho Webhook
- Redis INCR —
rate:{{contact.phone}}:{{date:today}} - Condição — count > 10 → rejeitar mensagem
FAQ
Por que não conectar diretamente ao Redis?
Acesso direto ao Redis a partir de uma plataforma de automação compartilhada é uma preocupação de segurança e isolamento de rede. O padrão de proxy HTTP mantém credenciais e fronteiras de rede sob seu controle.
GET retorna null / vazio?
Chave inexistente ou expirada — normal em cache miss. Ramifique com Condição.
Posso usar Redis lists como filas?
Sim, se seu proxy expuser LPUSH/BRPOP. Para cargas pesadas de fila, considere serviços de fila dedicados.
Redis vs nó Variável?
Variável persiste durante uma execução do workflow. Redis persiste entre execuções e workflows (cache compartilhado).
Template KEYS em produção?
Evite em databases grandes — bloqueia o Redis. Use listagem baseada em SCAN no seu proxy.
Referência da API
| Item | Valor |
|---|---|
| ID do tipo de nó | redis_request |
| Executor | http_request |
| URL padrão | {{redis_api_url}} |
| Auth | Bearer {{redis_api_token}} |
| Body | JSON com command, key e campos específicos do comando |
Relacionados
Este artigo foi útil?
Precisa de mais ajuda? Falar com suporte