Playground sem conta | O que um sandbox público pode mostrar e por que ele precisa de teto

Quem avalia uma API (interface de programação de aplicações) de verificação de identidade quer ver a resposta antes de ler o contrato. O código de exemplo da documentação ajuda, mas não responde à pergunta que importa para o desenvolvedor: o que chega de verdade, em que formato, e como o webhook se comporta quando a decisão sai. Pedir cadastro, confirmação de e-mail e chave antes dessa resposta coloca uma barreira justamente no momento em que a pessoa ainda está decidindo se vale a pena.

O playground sem conta tira essa barreira, e com ela tira a credencial que normalmente limita quem usa. Este texto analisa o que um sandbox público pode mostrar com honestidade, o que ele não pode fazer de jeito nenhum e por que ele precisa de teto, com a forma certa de esse teto responder.

O que o mercado chama de sandbox, e o que muda sem conta

A referência de mercado é o sandbox atrás de conta. A documentação da Stripe diz que os sandboxes "simulam a criação de objetos reais sem afetar transações reais nem movimentar dinheiro real", e que, depois de criar a conta, o usuário é colocado num sandbox com chaves de teste. A mesma página registra que objetos de um modo não são acessíveis no outro. A documentação da Persona diz que o modo sandbox existe para testar a integração sem cobrança de uso e que "verificações reais não são executadas no modo sandbox", com um seletor que força aprovação ou reprovação para ver todos os estados.

Os dois modelos têm em comum a separação: nada do teste atravessa para a produção, e nada real é verificado. O que muda no playground público é o que vem antes. Sem conta, não há chave, não há organização, não há e-mail confirmado. A única coisa que o servidor sabe de quem chama é o que a rede e o navegador dizem, e isso muda o desenho de tudo o que vem depois.

O que um sandbox público pode mostrar

Pode mostrar o contrato inteiro. O pedido que o servidor do integrador faria, a resposta com o formato real, os estados que a verificação percorre e o webhook assinado chegando, com o cabeçalho de assinatura que a integração vai precisar validar. Isso é o que encurta a avaliação: a pessoa vê a forma do dado e a ordem dos eventos, que é o que nenhum exemplo estático entrega.

Pode também deixar escolher o desfecho, como faz o seletor da Persona. Um sandbox que só mostra o caminho aprovado esconde justamente a parte que a integração precisa tratar, a reprovação e a revisão. Escolher o resultado e ver o evento correspondente é o jeito de mostrar que o caminho de erro existe e tem forma estável. O artigo sobre sandbox antes de produção trata de por que o determinismo é a propriedade que torna um ambiente de teste útil.

Na UNIFOKAL, o playground roda a integração em três passos no ambiente de testes: o seu servidor cria a sessão, a sua página monta o widget e o seu servidor recebe o webhook assinado, com o código de cada passo. O titular é de teste, nenhum dado seu é pedido e nenhuma câmera é aberta.

O que ele não pode fazer

Não pode receber dado real. Uma página aberta sem conta que aceitasse CPF (Cadastro de Pessoas Físicas), foto de documento ou selfie receberia dado pessoal de alguém com quem não existe relação nenhuma: nenhum contrato, nenhuma finalidade combinada, nenhum responsável identificado do outro lado. O titular sintético não é economia, é a condição para a página existir.

Não pode acionar recurso pago de verdade. O OWASP (Open Worldwide Application Security Project) API Security Top 10, na categoria API4:2023, registra que alguns recursos de que uma API precisa são fornecidos por terceiros e "pagos por requisição, como envio de e-mails, SMS (mensagens de texto), chamadas telefônicas, validação biométrica". Um endpoint público que encostasse nesses recursos transformaria cada visitante, e cada robô, em custo direto.

Não pode produzir nada que sirva em produção. Nenhuma chave, nenhum identificador reaproveitável, nenhum objeto que atravesse de ambiente, na mesma linha do que a Stripe registra para os modos dela. A separação de ambientes que o artigo sobre sandbox e produção separados descreve vale aqui com mais força, porque do outro lado não há sequer uma conta para responsabilizar.

Por que tem teto

Porque um endpoint aberto é exatamente onde o OWASP pede limite. A API4:2023 considera vulnerável a API em que falta, ou está mal ajustado, ao menos um dos limites de recurso que lista, do tempo de execução ao teto de gasto com provedores terceiros. A mesma categoria diz que a exploração "exige requisições simples" e pode partir de um único computador ou de recursos de nuvem, e que pode levar à negação de serviço por esgotamento de recursos ou ao aumento de custo operacional. Entre as medidas de prevenção, a página lista limitar com que frequência um cliente interage com a API num intervalo definido e limitar quantas vezes um mesmo cliente executa uma mesma operação.

Mesmo sem nenhum recurso pago, cada execução num sandbox público consome processamento e entrega de webhook. Sem teto, ele vira o jeito mais barato de ocupar a infraestrutura que atende os clientes com conta. Com teto, ele é uma vitrine que aguenta o próprio sucesso.

A RFC 6585 (Request for Comments) do IETF (Internet Engineering Task Force), que define o status 429, deixa uma liberdade importante para esse caso: ela "não define como o servidor de origem identifica o usuário, nem como conta as requisições". Sem conta, a identificação é necessariamente aproximada, e faz sentido que o teto mire o visitante que quer ver a API funcionar, não o volume de um teste de carga. Quem precisa de volume precisa de conta e de sandbox próprio.

Como o teto deve responder

O teto que bloqueia em silêncio parece defeito. O que avisa parece regra. A RFC 6585 diz que a resposta 429 "SHOULD" incluir detalhes que expliquem a condição e "MAY" incluir o cabeçalho Retry-After indicando quanto esperar antes de uma nova requisição. A mesma seção determina que respostas 429 "MUST NOT" ser armazenadas por cache. A RFC 9110, na seção 10.2.3, define o Retry-After como uma data HTTP (protocolo de transferência de hipertexto) ou um número de segundos.

Do lado da página, isso vira uma frase legível: limite atingido, tente de novo em tanto tempo, calculado a partir do cabeçalho. Do lado de quem estuda a API, vira a primeira demonstração do comportamento que a integração de produção também vai encontrar, e que o artigo sobre limite de taxa em API detalha: ler o cabeçalho, esperar e não insistir em laço.

Os valores de um teto assim são calibração operacional e não precisam fazer parte do contrato. O que faz parte é a forma da resposta: o código, o motivo e quando voltar.

Perguntas frequentes

O playground substitui o sandbox com conta?

Não. Ele mostra o contrato e os desfechos para quem está avaliando. A integração de verdade precisa da chave de teste, do webhook apontado para o seu servidor e de volume que um sandbox público não oferece.

Por que o playground não aceita meu próprio CPF para testar?

Porque uma página sem conta não tem como tratar dado pessoal com finalidade e responsabilidade definidas. O titular sintético mostra o mesmo formato de resposta sem que nenhum dado seu seja pedido.

Fontes citadas

• OWASP, API Security Top 10 2023, API4:2023 Unrestricted Resource Consumption: owasp.org
• IETF, RFC 6585, Additional HTTP Status Codes, seção 4 (429 Too Many Requests), abril de 2012: rfc-editor.org
• IETF, RFC 9110, HTTP Semantics, seção 10.2.3 (Retry-After), junho de 2022: rfc-editor.org
• Stripe, Testing use cases (sandboxes), documentação oficial, lida em 1º de outubro de 2026: docs.stripe.com
• Persona, Environments, documentação oficial, lida em 1º de outubro de 2026: docs.withpersona.com