O que mudou nas entradas de integração e na documentação da API do Steel, da mais recente para a mais antiga, e como acompanhar as próximas mudanças.
Nesta página
Como as mudanças chegam
Versão: o Steel usa versões por data (AAAA.MM.DD), a mesma do produto. A
versão da API aparece no topo da referência.
Compatibilidade: campos novos podem aparecer nas respostas a qualquer
momento; o seu código deve ignorar campos que não conhece. Remover ou renomear
um campo, mudar um código de erro ou o comportamento de uma entrada de
integração é anunciado aqui antes.
18/10/2026: API v1, tokens pessoais, webhooks enviados e Steel CLI
Nova API pública v1 em /api/v1/..., com a política de
estabilidade própria: nada é removido nem muda de tipo, e uma rota só sai
depois de 6 meses com Deprecation e Sunset. Cobre GET /api/v1/me,
chamados do ServiceDesk (listar, ver por id ou número, abrir, comentar e mudar
de fase), catálogo, leads (listar, criar e importar CSV de até 5.000 linhas),
oportunidades (listar e mudar de etapa), funis, templates do WhatsApp, envio
de template e andamento de disparo. A referência fica em
/dev/api/v1, e o documento em /dev/api/v1/openapi.json. O
CI do Steel compara o documento a cada mudança e falha se um campo some ou
muda de tipo.
Listas da v1 paginam por cursor: limit (padrão 25, máximo 100), cursor e
data.nextCursor. Escritas são auditadas com source: api e exigem o
consentimento LGPD do usuário (403 FORBIDDEN sem ele).
Novo token pessoal (Authorization: Bearer stl_pat_…), a única forma de
acesso da v1; o cookie de sessão e a chave crm_live_ não valem lá. Cada
token tem um workspace, módulos, escopo api:read ou api:read +
api:write e validade de 1 a 365 dias (padrão 90). Até 50 tokens ativos por
pessoa (422 API_TOKEN_LIMIT_REACHED). Novos códigos
403 API_TOKEN_SCOPE_REQUIRED e 403 API_TOKEN_MODULE_NOT_ALLOWED. Limite
de 300 requisições a cada 60 segundos por token, além do limite do usuário.
Veja Autenticação e chaves.
Rotas do aplicativo para os tokens: e
e (o próprio usuário, em ), e e
(dono e administradores,
em ).
GET
POST /api/users/me/api-tokens
DELETE /api/users/me/api-tokens/{id}
Configurações ›
Segurança › Tokens de API
GET /api/workspaces/{id}/api-tokens
DELETE /api/workspaces/{id}/api-tokens/{tokenId}
Ajustes › Apps conectados
Fluxo de dispositivo para o login do CLI: POST /api/v1/auth/device (sem
token) devolve deviceCode, userCode, verificationUriComplete,
interval (5 s) e expiresIn (600 s); POST /api/v1/auth/device/token
responde 428 AUTHORIZATION_PENDING, 429 SLOW_DOWN, 410 EXPIRED_TOKEN,
403 ACCESS_DENIED ou 200 com o token, uma vez só.
DELETE /api/v1/auth/token revoga o token da chamada (204). A confirmação é na
página /device.
Webhooks enviados: o Steel passa a avisar os seus sistemas quando algo
acontece no workspace, com eventos do ServiceDesk, do CRM, da Comunicação e
dos Steel Agents. Cada entrega é um POST assinado com
Steel-Signature: v1=<HMAC-SHA256>, com Steel-Webhook-Id e
Steel-Webhook-Timestamp; até 6 tentativas, desativação depois de 3 dias
falhando, log de 30 dias com reenvio e até 20 endpoints por workspace. Na
tela, em Ajustes › Webhooks; pela API, em
/api/v1/webhooks/events, /api/v1/webhooks/endpoints e
/api/v1/webhooks/deliveries. Veja
Webhooks que o Steel envia.
GET /api/v1/webhooks/listen (Server-Sent Events) entrega os eventos em
tempo real, com o corpo e os cabeçalhos exatos, e
POST /api/v1/webhooks/trigger cria um evento de teste que nunca chega aos
endpoints cadastrados. Os dois são para dono e administradores.
Steel CLI 0.1.0, no repositório público
steel-so/steel-cli: Homebrew
(brew install steel-so/tap/steel), script de instalação, npm
(@steel-so/cli) e binários para Linux, macOS e Windows. Login pelo
navegador, perfis, comandos de ServiceDesk, CRM e Comunicação, steel api,
steel listen e steel trigger, painel interativo, steel mcp, saída em
JSON e códigos de saída estáveis. Veja também
CLI em scripts e no CI e
Webhooks na sua máquina com o CLI.
SDK TypeScript @steel-so/sdk 0.1.0, gerado do documento da
v1: cliente tipado, atalhos por módulo, collectAll, resultados sem exceção,
waitForDeviceToken e verifySignature para conferir webhooks.
17/10/2026: servidor MCP
Novo servidor MCP em POST /api/mcp (Streamable HTTP, sem
estado). GET e DELETE respondem 405. Sem token, ou com token revogado,
a resposta é 401 com
WWW-Authenticate: Bearer resource_metadata="<origem>/.well-known/oauth-protected-resource".
O Steel passa a ser um servidor de autorização OAuth 2.1: código de
autorização com PKCE (S256), registro dinâmico de cliente, refresh e
revogação. Os endereços de cada etapa estão nos metadados, em
/.well-known/oauth-authorization-server e
/.well-known/oauth-protected-resource. Os tokens são opacos (stl_at_… e
stl_rt_…); o access token vale 1 hora e o refresh token, pedido com
offline_access, 30 dias.
Escopos mcp:read (ferramentas de leitura, resources e prompts) e
mcp:write (também criação, edição e ação, se o workspace ligou
mcpWriteEnabled em PATCH /api/workspaces/{id}/ai-settings). Ferramentas
de exclusão nunca são expostas.
Escritas que chegam a um cliente final (customerFacing) não executam pela
chamada: o resultado traz o link absoluto para confirmar a ação no Steel. As
ferramentas de escrita aceitam o argumento opcional idempotencyKey: a mesma
chave, na mesma conexão e ferramenta, não repete a ação por 24 horas.
Resourcessteel://servicedesk/kb/{id} e steel://wiki/pages/{id} (em
Markdown, 50 por página) e os promptsservicedesk_daily_summary,
crm_weekly_pipeline e whatsapp_unanswered_conversations.
Os href devolvidos pelas ferramentas vêm absolutos.
Limites de 120 chamadas por minuto por usuário e 600 por cliente OAuth,
com 429 e Retry-After.
Novas rotas de Apps conectados, na referência da API: listar
e revogar as conexões do próprio usuário e, para donos e administradores, as
de todos os membros do workspace.
14/10/2026: limites mensais do WhatsApp
Novo GET /api/workspaces/{id}/whatsapp/usage, com o uso do mês e os limites
de conversas e de mensagens enviadas do módulo Comunicação, e
PATCH /api/workspaces/{id}/whatsapp/usage para defini-los (donos e
administradores; null é sem limite, o padrão).
Com o limite atingido, o envio de mensagens (texto, mídia, contato e modelo, em
conversas e grupos) responde 402 WHATSAPP_MESSAGE_LIMIT_REACHED, e abrir ou
reabrir uma conversa responde 402 WHATSAPP_CONVERSATION_LIMIT_REACHED. O mês
segue o calendário de São Paulo.
Reações não contam e não são bloqueadas. Mensagens recebidas continuam
chegando, e os webhooks não mudam.
09/10/2026: site de desenvolvedores
Guias em /dev: começando, autenticação e chaves, formato de resposta e erros,
limites de requisição, paginação, webhooks e quatro guias por caso de uso.
A tabela de códigos de erro passa a ser gerada do registro central de erros da
API.
A referência da API passa a ser pública em /dev/api, sem as rotas internas de
operação. O endereço antigo /reference redireciona para ela.
08/10/2026: GitHub e GitLab no workspace
Novas entradas POST /api/integrations/github/webhook e
POST /api/integrations/gitlab/webhook: o GitHub e o GitLab passam a ser
conectados uma vez por workspace, em Ajustes › Integrações.
GitLab (gitlab.com e self-managed), verificado por X-Gitlab-Token e
idempotente por X-Gitlab-Event-UUID.
O endereço anterior do GitHub, POST /api/servicedesk/integrations/github,
continua aceito, com o mesmo comportamento.
02/10/2026: Slack e GitHub no ServiceDesk
Primeira versão do webhook do GitHub, com assinatura X-Hub-Signature-256 e
idempotência por X-GitHub-Delivery.
Entrada do app do Slack (POST /api/servicedesk/integrations/slack) para abrir
chamados por atalho e espelhar respostas de thread.
01/10/2026: chamados por monitoramento
Nova entrada POST /api/servicedesk/monitoring/<token>: abre, atualiza,
reabre e encerra chamados a partir do Zabbix ou de qualquer sistema, com
deduplicação por externalId.
23/07/2026: integrações do CRM
Nova entrada POST /api/crm/integrations/leads, com chave de API
(Authorization: Bearer crm_live_...), deduplicação contra leads em aberto e
resposta 200 para lead existente.
Formulários públicos: GET /api/crm/forms/<token> e
POST /api/crm/forms/<token>/submit.
Gatilho Webhook dos workflows: POST /api/crm/workflows/<token>/trigger.
