Get in Touch

Have a question about the platform, need help with your integration, or want to discuss partnership opportunities and enterprise pricing? Drop us an email — we’ll do our best to get back to you within 3–4 hours.

contact@fiwano.com
Menu da documentação

Documentação da API Fiwano

Feito para pessoas e agentes de IA

Cada página aqui é legível por humanos — guias por tarefa e conceitos — apoiada por um contrato OpenAPI completo. A mesma referência vem em um cookbook aberto que você clona no seu projeto em segundos.

Trabalhando com um agente de IA? Clone o cookbook

Recomendado

Aponte seu agente para o PLAYBOOK.md — um guia passo a passo para a referência da API e exemplos prontos, para ele ler só o necessário em cada etapa.

Ver o cookbook no GitHub

Prefere colar como contexto? Baixe a documentação completa em um único arquivo Markdown, ou pegue só a spec.

Baixar .md Spec bruta: openapi.json · openapi.yaml

Autenticação

Todas as requisições à API exigem uma chave de API no header X-API-Key. Clientes que só aceitam bearer token podem enviar a mesma chave como Authorization: Bearer YOUR_API_KEY; quando os dois headers estão presentes, vale o X-API-Key.

Crie uma chave na página API Keys do portal. A chave completa é exibida apenas uma vez — guarde-a com segurança. Chaves perdidas não podem ser recuperadas; revogue e crie uma nova.

curl https://fiwano.com/api/v1/channels \
  -H "X-API-Key: YOUR_API_KEY"

Todas as chaves começam com mip_live_. As chaves são armazenadas como hash do nosso lado.

Chaves de API são secretas: chame a API a partir do seu servidor ou de funções de backend, nunca de código no lado do cliente. A API não aceita requisições cross-origin do navegador (CORS).

Compatibilidade

A Fiwano não tem números de versão. O contrato da API é o v1 (https://fiwano.com/api/v1), estável desde o lançamento público em março de 2026. O serviço é atualizado continuamente; os novos recursos aparecem no changelog (com feed Atom).

Toda mudança no v1 é aditiva:

  • novos endpoints;
  • novos parâmetros e campos opcionais de requisição;
  • novos campos em respostas e payloads de webhook;
  • novos tipos de evento de webhook e novos valores em conjuntos abertos, como status de entrega, dicas de erro e o tipo de mensagem recebida data.type (um tipo desconhecido é tratado como unsupported).

O que não muda: endpoints existentes, nomes, tipos e significados dos campos; a autenticação por X-API-Key (Authorization: Bearer é uma alternativa aceita); o esquema de assinatura dos webhooks. Novos tipos de evento de webhook nunca são ativados nos seus canais sem uma ação sua — você faz opt-in por canal via webhook_events.

O que sua integração precisa fazer para continuar compatível: ignorar campos que não conhece e ignorar tipos de evento que não ativou. Não trate um campo desconhecido ou um novo valor em um conjunto aberto como erro.

Se uma mudança incompatível um dia for inevitável, ela sairá como uma nova versão da API ao lado do v1, anunciada no changelog e por e-mail com antecedência. O v1 continua funcionando.