O que acontece se o slug já estiver ocupado?

POST /api/mocks responde 409 com o código de erro slug_taken e não cria nada. O slug continua indisponível enquanto o mock que o detém estiver vivo e volta a ficar disponível assim que esse mock é excluído ou expira. O mesmo código é devolvido para nomes que não podem ser usados por outros motivos, então leia-o simplesmente como: escolha outro slug.

Um slug personalizado torna o mock público?

Não mais do que antes, mas um slug legível é mais fácil de adivinhar do que um aleatório, então quem adivinhar a URL pode chamá-la. Mantenha segredos fora da resposta. O log de requisições continua privado por padrão: só abre com o admin_token, a menos que você tenha criado o mock com logs_public .

Posso mudar o slug depois?

Não. O slug é definido quando o mock é criado, e atualizar o mock com PUT o ignora. Para passar a outro endereço, crie um mock novo com o novo slug, aponte seus clientes para ele e exclua o antigo.

URL de mock estável com um slug personalizado

Escolha você mesmo o slug e a URL do mock sobrevive a cada exclusão e recriação: defina-a uma vez no .env, no CI e no Postman e pare de correr atrás de endereços novos.

Uma URL de mock aleatória é ótima para um teste descartável e um incômodo para tudo que precisa lembrá-la. Recrie o mock e o endereço muda, então o valor no seu arquivo .env, nos segredos do CI e no ambiente compartilhado do Postman fica desatualizado. Um slug personalizado deixa você escolher o endereço uma única vez: passe slug ao criar o mock, pela API, pela CLI ou pelo formulário web, e https://quickmock.dev/m/my-app-payments-dev continua funcionando depois de excluir e recriar o mock, enquanto ninguém mais reivindicar o nome.

Por que uma URL de mock aleatória atrapalha?

Todo mock criado sem slug recebe um slug aleatório de 12 caracteres, e para um teste descartável é exatamente o que se quer. Deixa de ser no momento em que a URL é anotada em algum lugar. Exclua o mock e crie de novo, e você recebe outro slug, então cada lugar que lembrava o endereço antigo agora aponta para o nada: o arquivo .env no notebook de um colega, o segredo nas configurações do CI, o ambiente de uma coleção compartilhada do Postman, a URL base na configuração do sandbox de um parceiro.

Um slug personalizado transforma o endereço em algo que você escolhe uma vez. https://quickmock.dev/m/my-app-payments-dev pode ser colado em todos esses lugares e esquecido. O mock por trás dele ainda pode ser excluído, substituído por outra resposta ou deixado para expirar e ser recriado; desde que você o crie com o mesmo slug, a URL que seus clientes usam nunca muda.

Também é simplesmente mais agradável de trabalhar. Um nome legível numa linha de log, num stack trace ou num pipeline que falhou diz qual mock está envolvido sem precisar procurar.

Como criar um mock com o seu próprio slug?

Passe slug ao criar o mock. Na API ele é só mais um campo JSON:

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{"slug":"my-app-payments-dev","method":"GET","response_status":200}'

A CLI tem uma opção para isso, e o formulário web tem um campo de slug personalizado ao lado do sufixo de caminho:

quickmock create -slug my-app-payments-dev -s 200 -b '{"status":"ok"}'

Um slug tem de 4 a 48 caracteres: letras minúsculas, dígitos e hifens, começando e terminando com uma letra ou um dígito. Espaços no começo e no fim são removidos e letras maiúsculas viram minúsculas, então My-App-Dev vira my-app-dev. Omita o campo, ou envie-o vazio, e você recebe um slug aleatório como antes. Um slug com formato inválido é rejeitado com 422 validation_failed e nada é criado.

Se o nome não puder ser usado, a resposta é 409 slug_taken. É a mesma resposta quando outro mock ativo tem o slug e quando o nome está indisponível por qualquer outro motivo, então escolha outro e tente de novo.

Por quanto tempo a URL continua sua?

Um mock com slug personalizado vive como qualquer outro mock. Ele expira depois dos ttl_seconds que você definir, ou depois do padrão do servidor se você não definir nenhum, e nunca pode viver mais de 30 dias a partir do momento em que foi criado. Até lá a URL continua respondendo.

Para mantê-lo vivo, estenda o prazo com o admin_token que você recebeu na criação:

curl -X POST https://quickmock.dev/api/mocks/my-app-payments-dev/extend \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Isso adianta a data de expiração, mas nunca além do teto de 30 dias. Quando o teto é atingido, a chamada devolve 409 ttl_cap_reached e o mock expira no prazo.

Um slug é liberado assim que o mock some. Exclua o mock com DELETE /api/mocks/<slug>, ou deixe-o expirar, e a próxima requisição de criação já pode reivindicar o mesmo slug, com outro método, status ou corpo se quiser. É assim que se renova uma URL estável: o endereço fica, o mock por trás é novo e vem com um admin_token novo.

O que costuma dar errado?

Colocar segredos na resposta. Um slug legível é fácil de adivinhar, e quem adivinha pode chamar a URL. Trate o corpo da resposta como público: nada de chaves reais, tokens ou dados pessoais. O log de requisições é outra coisa e é privado por padrão: só abre com o admin_token, a menos que você tenha criado o mock com logs_public.
Escolher um nome genérico. Quem chega primeiro leva. Nomes como test, demo ou api quase certamente já estão ocupados. Coloque no slug um prefixo com a sua equipe e o seu aplicativo, por exemplo acme-checkout-staging.
Achar que o slug está reservado para você. Ele pertence a um mock apenas enquanto esse mock está vivo. Quando expira, qualquer pessoa pode criar um mock com o mesmo slug, então estenda o mock antes do prazo e guarde o admin_token num lugar onde você o encontre.
Esperar poder renomear. O slug fica fixo na criação, e atualizar o mock com PUT nunca o altera. Para outro endereço, crie um mock novo e exclua o antigo.

Quando usar isso

Slugs aleatórios mudam a cada recriação, então qualquer configuração que guardou a URL fica desatualizada. Um slug personalizado de 4 a 48 caracteres dá ao mock um endereço fixo e legível, que você pode fixar em ambientes, segredos do CI e configurações da equipe.

Criar o mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "slug": "my-app-payments-dev",
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"status\":\"ok\"}"
}'

Chamá-lo

curl https://quickmock.dev/m/<slug>

O que você obtém

GET /m/my-app-payments-dev -> 200 {"status":"ok"}
second create with the same slug -> 409 slug_taken
(until the first mock is deleted or expires)

FAQ

O que acontece se o slug já estiver ocupado?: POST /api/mocks responde 409 com o código de erro slug_taken e não cria nada. O slug continua indisponível enquanto o mock que o detém estiver vivo e volta a ficar disponível assim que esse mock é excluído ou expira. O mesmo código é devolvido para nomes que não podem ser usados por outros motivos, então leia-o simplesmente como: escolha outro slug.
Um slug personalizado torna o mock público?: Não mais do que antes, mas um slug legível é mais fácil de adivinhar do que um aleatório, então quem adivinhar a URL pode chamá-la. Mantenha segredos fora da resposta. O log de requisições continua privado por padrão: só abre com o admin_token, a menos que você tenha criado o mock com logs_public.
Posso mudar o slug depois?: Não. O slug é definido quando o mock é criado, e atualizar o mock com PUT o ignora. Para passar a outro endereço, crie um mock novo com o novo slug, aponte seus clientes para ele e exclua o antigo.

Construa o seu próprio

Criar um mock

Guias relacionados

← Todos os guias

Última atualização: 2026-10-20