Como o acesso funciona
- A unidade de isolamento é a organização. Número, templates, contatos, conversas, opt-outs, campanhas, automações, webhook, base de conhecimento do Brain, carteira e faturamento pertencem a ela.
- Cada usuário (e-mail) pertence a uma organização por vez.
- A chave de API pertence ao usuário que a criou e age na organização desse usuário.
- Não existe troca de organização por API: cada chave age em uma organização só.
Antes de começar
- Um e-mail da agência exclusivo para cada cliente.
- Um cofre de segredos para guardar uma chave de API por cliente.
- O CLI instalado, se você for operar pelo terminal.
Passo a passo
1
O cliente cria a organização
O cliente cria a conta na Arara com os dados dele e conecta o número. Ele continua dono da organização (
OWNER) e dos dados.2
O cliente convida a agência
Pelo painel ou pela API, com o e-mail da agência reservado para esse cliente:Aqui
ARARA_API_KEY é a chave do cliente. Papéis: ADMIN, DEVELOPER, AGENT, BILLING, VIEWER. OWNER não é atribuído por convite, só por transferência. Só OWNER e ADMIN convidam.3
A agência entra com esse e-mail
Quem entra pela primeira vez com um e-mail que tem convite pendente já cai na organização do cliente, com o papel do convite.
4
A agência cria a chave de API
Dentro dessa organização, crie a chave pelo painel, em API Keys. Criar e gerenciar chaves exige sessão do painel de um
OWNER ou ADMIN (VIEWER só cria chave restrita a envio). Chamada autenticada com chave de API recebe 403. A chave completa só aparece na criação: guarde no cofre.Na criação ou na edição, restrinja a chave:ipAllowlist: IPs ou faixas CIDR separados por vírgula. Chamada de fora da lista é recusada. Depende do plano.permissionsescope: o que a chave pode fazer.dailySendLimit: teto de envios por dia.expiresAt: validade.
5
Use uma instância do SDK por cliente
idempotencyKey um valor derivado do evento do cliente, por exemplo clientex-pedido-12345-confirmacao. Com muitos clientes, guarde as chaves criptografadas no seu banco ou em um gerenciador de segredos, nunca no código nem no frontend.6
Separe os webhooks por organização
Cada organização tem o próprio webhook e o próprio secret. No seu endpoint, use o
organizationId do payload para saber de qual cliente é o evento e valide a assinatura com o secret daquela organização. Ver Webhooks.7
No terminal, use um profile por cliente
Cada profile do CLI guarda a própria credencial:
Armadilhas
arara org usenão troca a credencial.arara org listearara org useexistem, mas a chave continua agindo na organização do usuário. Para trocar de cliente, troque de profile.- Não há visão agregada. Consulte cada organização com a chave dela (
GET /v1/campaigns,GET /v1/contacts/stats,GET /v1/recovery/stats) e consolide do seu lado. - Cada cliente paga o próprio consumo. Carteira e assinatura são da organização. A cobrança da agência pelo serviço é feita por fora da Arara. Para revenda sob a sua marca, fale com contato@ararahq.com.
Auditoria e revogação
- Chave vazou: revogue só ela, em API Keys ou com
DELETE /v1/api-keys/{id}pela sessão do painel. As outras organizações não são afetadas. GET /v1/api-keys/{id}/events: histórico da chave (criada, revogada, rotacionada, mudança de escopo ou IP), comactorUserIde data.GET /v1/api-keys/{id}/stats: volume de chamadas e taxa de sucesso em 7 e 30 dias.GET /v1/team/audit-log: eventos do time (convites, mudanças de papel, remoções).
events e stats exigem sessão do painel de OWNER ou ADMIN e não aceitam chave de API. O audit log do time exige OWNER ou ADMIN.
Quando o cliente sai
- O cliente remove o usuário da agência em Time (ou
DELETE /v1/team/members/{id}). A remoção revoga todas as chaves de API desse usuário. - Apague do seu lado a chave e o profile do CLI (
arara profile remove cliente-x). - Se o cliente pedir, exporte os contatos (
GET /v1/contacts/export) antes da saída.
Próximos passos
CLI
Profiles e login.
Chaves de API
Permissões, limites e rotação.
Webhooks
Assinatura e secret por organização.