Sua equipe de frontend está bloqueada. O design foi aprovado, as telas estão semi-construídas, e a única coisa que impede o progresso é uma API que ainda não existe. O backend ainda está a um sprint de distância, então a UI não tem nada real para chamar. A solução paliativa usual é um mock local, e funciona até o momento em que você fecha seu laptop. Então, o endpoint que seu colega de equipe em outro fuso horário estava usando fica inativo.
É essa lacuna que o Apidog preenche com o Cloud Mock. Em vez de um mock que vive e morre em uma única máquina, você obtém uma URL pública hospedada em mock.apidog.com que permanece ativa 24 horas por dia. Desenvolvedores de frontend, QA e parceiros podem acessar endpoints realistas antes mesmo que uma única linha de código de backend seja entregue. Se você quer ter uma visão mais ampla do que o mocking oferece a uma equipe, nosso guia sobre o que é um mock de API e quando usá-lo prepara o terreno. Para os mecanismos de como uma URL de mock pública se encaixa no tratamento de solicitações, a referência MDN sobre o modelo de solicitação/resposta HTTP é uma ótima atualização.
O que é o Cloud Mock e por que os mocks locais ficam aquém
O Apidog gera um endpoint de mock para cada API que você projeta. Por padrão, esse mock é um mock local: ele é executado a partir da sua instância do Apidog e responde enquanto sua máquina está ligada. No momento em que você desliga, o endpoint para de responder. Isso é bom para depuração individual. Mas desmorona no instante em que outra pessoa depende da URL.
O Cloud Mock é a solução. É um endpoint de mock continuamente disponível que persiste independentemente de qualquer máquina individual. Os computadores de seus colegas de equipe podem estar desligados, seu laptop pode estar na bolsa, e o mock na nuvem continua respondendo às solicitações 24 horas por dia, 7 dias por semana. O endpoint reside no serviço hospedado do Apidog, então a disponibilidade não está atrelada a quem está online.
O benefício prático é uma entrega limpa. Você projeta o contrato, ativa o Cloud Mock e compartilha uma única URL. O frontend constrói com base em dados realistas, o QA escreve casos de teste com base em formatos de resposta reais, e um parceiro que se integra a você pode começar a conectar seu cliente imediatamente. Ninguém espera pelo backend, e ninguém espera que você mantenha um processo em execução. Se você está coordenando isso entre regiões, os padrões em compartilhamento de mock servers e ambientes com equipes globais aprofundam o fluxo de trabalho.
Habilite o Cloud Mock e obtenha sua URL pública
Vamos analisar isso com uma API realista. Digamos que você esteja construindo um serviço de usuários com um endpoint GET /users que retorna uma lista de registros de clientes. Veja como você transforma isso em um endpoint na nuvem compartilhável.
Passo 1: Ative o Cloud Mock
Abra seu projeto e vá para Project Settings > Feature Settings > Mock Settings. Ative o Cloud Mock. Essa é a chave que informa ao Apidog para hospedar seus mocks em seu serviço sempre ativo, em vez de servi-los apenas localmente.
Você só faz isso uma vez por projeto. Depois de ativado, cada endpoint no projeto obtém uma URL de mock na nuvem, juntamente com sua URL local.
Passo 2: Copie a URL do Cloud Mock
Abra o endpoint que você deseja compartilhar, GET /users neste caso. Vá para a guia Mock e copie a URL do Cloud Mock. Você obterá algo parecido com isto:
https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
A estrutura do caminho segue um padrão: mock.apidog.com/m1/<projectId>-<num>-<env>/<path>. O Apidog o constrói para você, então você não precisa montá-lo manualmente. Observe que a documentação mostra isso por exemplo, em vez de publicar um modelo fixo, então trate a URL copiada como a fonte da verdade em vez de tentar construir uma você mesmo.
Passo 3: Teste o mock instantaneamente dentro do Apidog
Antes de entregar a URL a alguém, confirme se ela retorna o que você espera. Na mesma guia Mock, envie uma solicitação de teste contra a URL do mock. O Apidog dispara a solicitação e mostra a resposta ali mesmo. Você obtém uma leitura instantânea se os dados gerados parecem corretos.
Um mock de GET /users pode retornar algo assim:
[
{
"id": 1,
"name": "Amelia Turner",
"email": "amelia.turner@example.com",
"city": "Portland"
},
{
"id": 2,
"name": "Marcus Bell",
"email": "marcus.bell@example.com",
"city": "Austin"
}
]
Esses valores não são codificados. O Apidog lê os nomes e tipos dos campos do seu esquema e gera dados plausíveis para corresponder, o que torna o mock útil para um frontend que renderiza uma tabela com aparência real.
Passo 4: Abra a URL em um navegador
Para uma solicitação GET, a URL do mock na nuvem funciona diretamente em um navegador da web. Cole-a na barra de endereços e você verá a resposta JSON. Esta é a verificação de sanidade mais rápida que você pode dar a um stakeholder não técnico: nenhum cliente, nenhum curl, apenas um link que retorna dados.
Para algo além de uma olhada rápida, seu frontend a chama como qualquer outro endpoint:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Esse é todo o ciclo. Projete o endpoint, habilite o Cloud Mock, copie a URL e sua equipe será desbloqueada.
Bloqueie o mock com autenticação por token
Uma URL pública é conveniente, e às vezes, conveniente demais. Se seu mock reflete um recurso não lançado ou uma integração de parceiro que você preferiria não expor, você pode protegê-lo.
Vá para Project Settings > Feature Settings > Mock Settings e defina a permissão de acesso para Token Authentication. Uma vez ativada, cada solicitação deve carregar um apidogToken válido, e as solicitações sem ele serão rejeitadas. Você pode fornecer o token de três maneiras:
Como um parâmetro de string de consulta da URL, que é o que a URL copiada já usa:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Como um cabeçalho de solicitação, que mantém o token fora da URL e dos logs do servidor:
curl "https://mock.apidog.com/m1/2689726-0-default/users" \
-H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Ou como um parâmetro de corpo chamado apidogToken em uma solicitação form-data ou x-www-form-urlencoded, que se adequa a clientes que publicam corpos de formulários.
Para código frontend, a abordagem do cabeçalho é geralmente a mais limpa. Ela mantém o token fora de qualquer coisa que registre URLs completas e separa a credencial do caminho do recurso:
const res = await fetch(
"https://mock.apidog.com/m1/2689726-0-default/users",
{ headers: { apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi" } }
);
const users = await res.json();
Uma coisa a planejar: se você habilitar a Autenticação por Token depois de já ter compartilhado uma URL simples, todo consumidor precisará adicionar o token ou suas chamadas começarão a falhar. Coordenar a mudança para que o QA e os parceiros não fiquem olhando para solicitações rejeitadas.
Gere dados realistas e conscientes da região com locais
Um mock que retorna "name": "string" para cada registro não ensina nada à sua UI. Um mock que retorna nomes, endereços e números de telefone com aparência real permite que o frontend detecte bugs de layout, estouro de texto e problemas de formatação antes que os dados reais cheguem. O Apidog lida com isso usando Faker.js por trás dos panos, e os controles de localidade são onde ele se torna genuinamente útil para produtos internacionais.
Como o local padrão funciona
Por padrão, o Faker segue a configuração de idioma do seu projeto. Isso é configurado em Project Settings > Basic Settings, e qualquer idioma que você escolher lá se torna o local padrão para todos os valores de mock gerados. Defina o projeto para francês e seus nomes e endereços de mock virão com um toque francês, sem nenhum trabalho por campo.
Substitua o local para todo o projeto
Se você deseja dados de mock em um local específico que difere do idioma do projeto, pode substituí-lo. Vá para Project Settings > Feature Settings > Mock Settings e escolha um local do Faker na lista suspensa. Essa substituição prevalece sobre o padrão de idioma das Configurações Básicas para cada campo do projeto.
Isso é útil quando você está testando a internacionalização. Aponte o local do projeto para o Japão e cada endereço, nome e número de telefone gerado refletirá essa região, para que você possa ver como sua UI se comporta com scripts não latinos e diferentes formatos de endereço. A geração automática desse tipo de dado consciente do esquema é um tópico por si só, e o passo a passo sobre o smart mock do Apidog e como ele lê seu esquema aborda o lado da geração em detalhes.
Substitua o local campo a campo
Às vezes, você precisa de um campo em um local diferente do restante, digamos, uma lista de clientes que mistura regiões. Você pode definir o local diretamente na expressão do mock usando o parâmetro locale:
{{$person.fullName(locale='ja')}}
Isso produz nomes japoneses como 田中 太郎 apenas para aquele campo, enquanto o restante da resposta segue o local do projeto. A precedência ocorre em três níveis: um local em nível de campo substitui o local em nível de projeto, que substitui o padrão de idioma das Configurações Básicas. Assim, você define um padrão de projeto sensato e só usa as substituições em nível de campo onde realmente precisa da exceção.
Uma nota honesta sobre o escopo: a documentação mostra `ja` como o exemplo trabalhado e não publica uma lista completa de locais suportados, então confirme o código exato para sua região-alvo na documentação de mock do Apidog antes de confiar nele. As próprias convenções do Faker são documentadas na referência de locais do Faker.js.
Combine também o fuso horário
Há um controle paralelo para o tempo. Um padrão em nível de projeto reside em Project Settings > Feature Settings > Mock Settings, e você pode sobrescrever por campo com o parâmetro `timeZone` dentro de uma expressão mock. Se sua UI renderiza timestamps, isso mantém os valores `createdAt` gerados consistentes com a região que você está simulando, em vez de usar o padrão do local onde seu servidor está.
Entre os controles de localidade e fuso horário, você pode criar um mock que imita de forma convincente uma base de usuários japonesa, alemã ou uma coorte internacional mista, tudo a partir do mesmo esquema de endpoint. Para o conjunto mais amplo de cenários que isso desbloqueia, a coletânea de casos de uso práticos de mocking de API vale a pena conferir.
Cloud Mock versus um mock auto-hospedado
O Cloud Mock é a opção hospedada do Apidog, e atende à maioria das equipes. Se sua organização possui regras de residência de dados ou uma política contra o roteamento de tráfego de teste através da nuvem de um fornecedor, o Apidog também oferece suporte à execução do serviço de mock em sua própria infraestrutura. A troca é direta: a opção na nuvem é de configuração zero e está sempre ativa, enquanto a auto-hospedagem lhe dá controle ao custo de executar o serviço por conta própria. Se essa é sua situação, o guia para auto-hospedar o servidor de mock do Apidog o orienta. Para equipes que avaliam opções hospedadas lado a lado, a comparação de ferramentas de mocking de API online apresenta o cenário.
Sobre a restrição de planos, uma resposta direta: os recursos de Cloud Mock e local documentados aqui não indicam um requisito de plano específico, então o correto é verificar a disponibilidade atual em sua própria conta, em vez de tirar um número de uma postagem de blog. Você pode baixar o Apidog e experimentar o fluxo de ponta a ponta para ver exatamente o que seu espaço de trabalho inclui.
Automatize o fluxo de trabalho com o Apidog CLI
O mocking no Apidog é uma capacidade de GUI e nuvem. As respostas de mock são geradas automaticamente a partir do esquema do seu endpoint e servidas pelo motor hospedado do Apidog, e não por algo que você executa em um terminal. Portanto, a abordagem honesta é esta: o Apidog CLI não inicia nem serve um servidor mock. O que ele faz é manter as entradas do seu mock precisas.
A CLI e agentes de codificação de IA como Cursor ou Claude Code podem criar e atualizar os endpoints e esquemas em seu projeto. Como o mock na nuvem lê esses esquemas para gerar dados, manter a especificação atualizada mantém a saída do mock honesta à medida que a API evolui. Quando você usa uma ferramenta agêntica para adicionar um campo, o mock o reflete sem uma edição manual.
Então, uma vez que o mock desbloqueou o trabalho de frontend e o backend real é implementado, os mesmos cenários de teste do projeto são executados sem interface contra ele. O comando de execução da CLI valida o backend ao vivo contra o mesmo contrato que o mock descreveu:
apidog run -t <scenario_id> -e <env_id> -r cli
Esse único comando executa um cenário de teste salvo contra um ambiente e relata os resultados, de modo que o mock que desbloqueou a UI e os testes que verificam o backend ambos rastreiam a uma única fonte de verdade. Abra seu cenário no Apidog e copie o comando gerado com o ID do cenário `-t` e o ID do ambiente `-e` já preenchidos, em vez de montar as flags manualmente. A integração disso em um pipeline é abordada no guia sobre execução do Apidog em um pipeline CI/CD.
FAQ
A URL do mock na nuvem continua funcionando quando eu fecho o Apidog?
Sim, esse é o ponto principal do Cloud Mock. Ao contrário de um mock local, que para de responder quando a máquina host é desligada, o mock na nuvem é servido pela infraestrutura do Apidog e permanece disponível 24 horas por dia, 7 dias por semana. Seus colegas de equipe podem acessá-lo independentemente de seu computador estar ligado.
Posso usar a URL do mock na nuvem diretamente em um navegador?
Para solicitações GET, sim. Cole a URL completa, incluindo o parâmetro de consulta apidogToken, na barra de endereços e você verá a resposta JSON. Para outros métodos ou para manter o token fora do histórico do navegador, chame-o com uma ferramenta como curl ou seu cliente frontend e passe o token como um cabeçalho.
O que acontece com as requisições que não incluem o token?
Se você definiu a permissão de acesso para Autenticação por Token, qualquer requisição sem um apidogToken válido será rejeitada. Forneça-o como um parâmetro de string de consulta, um cabeçalho de requisição ou um parâmetro de corpo em uma requisição de formulário. Se você habilitar a autenticação por token depois de compartilhar uma URL simples, informe seus consumidores para que eles possam adicionar o token antes que suas chamadas comecem a falhar.
Como obtenho dados de mock que correspondem a um país específico?
Defina a localidade do seu projeto em Configurações Básicas, ou substitua-a para todo o projeto em Configurações de Recursos > Configurações de Mock, ou substitua um único campo com o parâmetro `locale` na expressão do mock, como `{{$person.fullName(locale='ja')}}`. O nível de campo prevalece sobre o nível de projeto, que prevalece sobre o padrão de Configurações Básicas. O passo a passo do smart mock mostra como a geração consciente do esquema se relaciona com isso.
Devo usar o Cloud Mock ou uma ferramenta de mock headless?
O Cloud Mock é adequado para equipes que desejam um endpoint hospedado e de manutenção zero, vinculado ao seu design de API. Se você precisa de mocks incorporados em uma construção automatizada sem nenhuma GUI, a pesquisa de ferramentas de mock de API headless compara as opções e onde cada uma se encaixa. A especificação da OpenAPI Initiative sustenta a maioria dessas ferramentas, então uma especificação limpa compensa qualquer caminho que você escolha.
Conclusão
Um mock que só existe no seu laptop desbloqueia apenas uma pessoa. O Cloud Mock o transforma em uma URL pública mock.apidog.com que toda a sua equipe pode usar, com autenticação por token quando você precisa protegê-lo e controles de localidade quando seus dados precisam parecer reais para uma região específica. Projete o endpoint, ative a chave, compartilhe o link, e o frontend para de esperar pelo backend. Baixe o Apidog para configurar seu primeiro mock na nuvem compartilhável, gratuitamente e sem necessidade de cartão de crédito.