Caso de uso

Quebre sua API de propósito.

Aponte qualquer cliente para o proxy e simule um 500, pause uma requisição no meio do caminho, ou exporte exatamente o que aconteceu como um HAR para entregar a um colega.

An Android phone, a browser and a backend server stream traffic into a central proxy hexagon on port 8888; one stream passes a block-and-script rule gate and comes out transformed, then one live stream flows on into a dashboard feed with green status codes. A globe marks upstream proxy routing. android browser server {} rules :8888 upstream live 200 201 200

O problema

Reproduzir um bug de API significa fingir o backend

Um endpoint lento, um corpo de erro malformado, uma condição de corrida entre duas chamadas — nada disso é fácil de provocar sob demanda a partir de um servidor real.

Para engenheiros backend e full-stack que constroem ou testam um cliente de API — um app mobile, um frontend, uma CLI, um job de CI — e precisam ver e controlar os bytes exatos na rede, não só a resposta que um SDK devolve.

O proxy-server da Busymate fica entre seu cliente e a API real. Cada requisição é capturada ao vivo, e o mesmo motor de regras de bloquear/simular/descartar que roda na captura iOS e Chrome também roda aqui — então você pode responder uma requisição real com uma pré-fabricada, ou descartá-la totalmente, sem tocar no backend.

Como resolve isso

Uma URL de PAC, todo o kit de ferramentas por trás

Sem SDK, sem agente para instalar — qualquer cliente que possa apontar para um proxy já está integrado.

Simule, bloqueie ou descarte na rede

Responda a uma requisição correspondente com seu próprio status, cabeçalhos e corpo — ou descarte-a — usando regras que rodam inline no próprio proxy, antes que a requisição chegue à API real.

Breakpoint, edite, reenvie

Pause uma requisição no meio do caminho, edite o HTTP bruto manualmente, depois continue ou reenvie — reproduza uma condição de corrida ou um payload malformado sem escrever uma linha de código de teste.

Exporte para HAR, ou acesse via REST

Exporte a troca exata como arquivo HAR para um colega ou um relatório de bug, ou acesse os mesmos dados capturados pela API REST simples baseada em PostgREST — sem necessidade de SDK em nenhum dos casos.

Superfícies envolvidas
  • Proxy
  • Dashboard
  • REST
  • MCP

Passo a passo

De um cliente instável a um relatório de bug reprodutível

Sem alterações de código em nenhuma das pontas.

  1. 01

    Aponte o cliente para o proxy

    Configure o cliente — um telefone, um navegador, um serviço de backend, um job de CI — a partir da única URL de auto-configuração PAC. O tráfego começa a fluir imediatamente.

  2. 02

    Reproduza a falha

    Simule o endpoint para retornar a resposta quebrada que você precisa, ou coloque um breakpoint e edite manualmente a requisição ou resposta real antes que ela continue.

  3. 03

    Exporte ou consulte o resultado

    Exporte a troca como HAR para anexar a um relatório de bug, ou puxe as mesmas entradas capturadas do seu conjunto de testes via API REST.

No proxy

Como funciona na linha

Um proxy fica entre o seu cliente e a API real; as regras rodam dentro dele.

  1. 01

    Aponte um cliente para o seu proxy

    Cada dispositivo tem sua própria identidade de proxy e uma URL de configuração automática. Cole essa URL nas configurações de Wi-Fi de um celular, num perfil de navegador ou na variável de proxy HTTP que um backend ou um job de CI lê, e as requisições dele começam a aparecer no feed do dashboard imediatamente.

  2. 02

    Escreva uma regra, ou pause a requisição

    Abra uma entrada e escolha o que deve acontecer da próxima vez: responder a requisição com seu próprio status, cabeçalhos e corpo, descartá-la, ou definir um breakpoint para que a próxima requisição correspondente pause no meio do caminho. Edite a requisição ou a resposta bruta à mão, depois continue ou reenvie.

  3. 03

    Entregue a troca a outra pessoa

    Exporte a requisição e a resposta como um arquivo HAR para um relatório de bug, ou leia as mesmas entradas capturadas de uma suíte de testes pela API REST. Ambos carregam os bytes exatos que cruzaram a linha, não a interpretação de um SDK.

FAQ

Antes de apontar um cliente, as perguntas de sempre

Meu cliente precisa de um SDK ou de mudança no código?

Não. Qualquer coisa que possa ser apontada para um proxy HTTP já está integrada — celulares, navegadores, serviços de backend, jobs de CI. O proxy cuida da captura e das regras; seu cliente continua falando com o que acredita ser a API real.

Posso simular só um endpoint e deixar o resto real?

Sim. As regras casam por padrões de host e caminho, então um endpoint pode devolver um 500 pronto enquanto todas as outras requisições passam intactas para o backend real.

Um breakpoint bloqueia o resto do tráfego?

Não. Só a requisição correspondente pausa; todo o resto continua fluindo. Continue, edite ou reenvie quando estiver pronto, e o cliente vê o resultado como se o servidor tivesse respondido.

Meus testes podem ler o tráfego capturado?

Sim. As entradas capturadas ficam disponíveis por uma API REST simples, então um teste de integração pode verificar o que o cliente realmente enviou em vez do que um mock esperava.

Pare de fingir o backend — controle a rede real

Aponte seu primeiro cliente para o proxy e simule, quebre ou reenvie sua primeira requisição em minutos.

Ask your mate