Pergunta “este fornecedor de eSIM tem uma API?” e vais receber muitos sins. Pergunta “um agente de IA consegue completar uma compra a partir dele, sozinho, sem um humano ao teclado?” e os sins evaporam-se quase todos. As duas perguntas soam parecidas e não são. A primeira é sobre se o software existe; a segunda é sobre se um comprador autónomo consegue chegar todo o caminho de “preciso de dados” a “aqui está o teu eSIM a funcionar” sem cair num passo que assume uma pessoa.
Essa segunda pergunta é a que importa se estás a construir um agente, e raramente é respondida com honestidade porque a resposta é normalmente não. Por isso, em vez de classificar marcas, este é um teste que podes correr tu mesmo. Cinco passos. Um fornecedor tem de passar nos cinco para que um agente consiga de facto comprar a partir dele; a maioria passa um ou dois.
O teste: o agente consegue chegar ao fim?
Percorre os cinco passos que uma compra exige e pergunta, em cada um, se um programa sem browser e sem ajuda humana o consegue completar.
- Consegue ler o catálogo sem um browser? Preços e cobertura têm de estar disponíveis como dados — uma API pública, um endpoint de catálogo, um
llms.txt— e não trancados dentro de uma montra JavaScript que só renderiza para um olho humano. - Consegue começar sem um registo? Se a primeira coisa exigida é uma conta — um email para confirmar, um fluxo OAuth para clicar — um agente sem caixa de entrada e sem browser fica preso antes de começar.
- Consegue pagar sem um humano num formulário de cartão? O checkout com cartão guardado assume uma pessoa a digitar um número numa página ligada a um cookie de sessão. Um agente precisa de um trilho que consiga de facto completar: um saldo que detém, uma transferência de stablecoin, um protocolo de pagamento agêntico — algo que não seja um formulário.
- Consegue receber o eSIM como dados, e não como um QR enviado por email a uma pessoa? A entrega tem de voltar pela API como um identificador mais superfícies de ativação que o agente possa usar — um URL de imagem QR, um payload em bruto, um link de instalação com um toque — e não um código enviado por email a um humano para ler com a câmara de um telemóvel.
- Pode confiar-se nele, e não apenas ser capaz? A capacidade técnica não chega. Sem tetos de gasto, escopos e um interruptor de emergência, “um agente pode comprar isto” significa na verdade “um agente pode esvaziar isto”, e ninguém deveria ligar isso. A autonomia limitada é a diferença entre uma demo e algo que de facto deixarias correr.
Como o panorama pontua de facto
Uma ressalva antes das categorias: este mercado move-se depressa, e os fornecedores adicionam capacidades. Trata o que se segue como uma forma de classificar, não como um veredicto permanente — e volta a correr os cinco passos tu mesmo antes de confiares em qualquer parte disto.
Marketplaces de consumo convencionais
Os nomes conhecidos — Airalo, Holafly, Nomad, Saily, Ubigi e o resto — são construídos, bem, para consumidores. O catálogo vive numa app ou numa montra JavaScript; comprar quer uma conta ou um cartão guardado; a ativação é um código QR feito para a câmara de um telemóvel. Vários oferecem APIs de parceiro ou B2B, mas essas ficam atrás de um acordo assinado e de um processo de aprovação dirigido a empresas, não a um agente individual a ligar algo esta tarde. No teste de cinco passos, tipicamente passam o passo 1 apenas parcialmente (uma API B2B fechada não é o mesmo que uma pública) e caem no registo, no formulário de cartão e na ausência de qualquer modelo de gasto de agente. São excelentes naquilo para que foram concebidos, que é um humano num checkout. A comparação Roamzy vs Airalo faz um deles passar pelo teste em detalhe e é franca sobre onde o estabelecido ainda ganha.
eSIMs de privacidade e cripto
Uma segunda categoria — Silent Link, Surfroam e serviços semelhantes de pendor pró-privacidade — resolve o passo de pagamento que tramoia os convencionais, ao aceitar cripto, e por vezes também flexibiliza o requisito de registo. Isso aproxima-os de forma significativa nos passos 2 e 3. Mas continuam, na sua maioria, a ser checkouts web voltados para humanos: sem API pública de agente nem servidor MCP para conduzir o fluxo programaticamente, e sem modelo de tetos de gasto e interruptor de emergência para autonomia delegada. Mais perto no trilho, ainda não construídos para serem conduzidos por um programa.
O grupo nativo para agentes
Uma terceira categoria, muito mais pequena e mais recente, está a construir para agentes de propósito — uma API pública ou um servidor MCP como porta de entrada, não como reflexão tardia. A Roamzy está nela; também estão esforços iniciais como o eSIM.dog e o eSIM Copilot. Esta é a única categoria onde passar nos cinco passos está sequer em cima da mesa, porque o fluxo foi concebido para um comprador não humano desde o início, em vez de adaptado a uma loja de consumo. É também minúscula e inicial — um punhado de nomes, não um mercado maduro — por isso o enquadramento honesto é “é aqui que vale a pena olhar”, e não “isto está resolvido”.
A correr o teste na Roamzy
Como esta é a nossa publicação, aqui está a Roamzy contra os seus próprios cinco passos, incluindo onde é fraca. Sem facilidades na avaliação.
- Ler o catálogo sem um browser — sim. Uma API REST pública com uma especificação OpenAPI, um endpoint de catálogo com CORS aberto, um llms-full.txt escrito para motores, e um servidor MCP com doze ferramentas disponível tanto como pacote npm como endpoint remoto ao qual te ligas por URL.
- Começar sem um registo — sim. Anónimo por omissão: o agente chama um endpoint, obtém uma sessão, e pode consultar preços e comprar sem conta. A identidade é opcional, à posteriori. Esta é a maior barreira que a maioria dos fornecedores nunca remove.
- Pagar sem um formulário de cartão — sim, com um asterisco honesto. O pagamento é em USDT ou USDC na rede à tua escolha, por isso não há formulário de cartão no circuito. O asterisco: um utilizador sem carteira cripto fica genuinamente pior aqui do que num checkout de cartão, e os trilhos nativos de pagamento agêntico on-chain que entusiasmam toda a gente ainda não estão ligados — isso exige uma tesouraria e está deliberadamente em pausa. O que funciona hoje é um link de pagamento que o utilizador liquida a partir de qualquer carteira.
- Receber como dados — sim. A resposta da encomenda devolve um número de telefone mais três superfícies de ativação: um URL de imagem QR, o payload QR em bruto, e um link de instalação com um toque, para que funcione quer o agente e o telemóvel sejam o mesmo dispositivo ou não.
- Poder confiar-se, e não apenas ser capaz — sim, e é este o ponto. Cada token carrega tetos diários e mensais, um teto de arrefecimento em tokens novos, uma porta de confirmação de transação grande, e três interruptores de emergência independentes; as sessões anónimas são mantidas mais apertadas do que as nomeadas. O guia do programador cobre o modelo.
Mais duas notas honestas. A camada de identidade OAuth está construída e publicada, mas devido a como os conectores se comportam hoje, fica maioritariamente por usar — a maioria dos agentes liga-se anonimamente, por design. E a categoria nativa para agentes em que a Roamzy se insere tem semanas, não anos. O que a Roamzy pode reivindicar é a mais completa combinação atual dos cinco — começo anónimo, trilho cripto, faturação por MB sem expiração, entrega programática, e um modelo de gasto real — não que esteja sozinha na categoria ou que a categoria esteja terminada.
O que faz a combinação importar
Qualquer um destes pode ser encontrado noutro lado. O pagamento cripto existe nos eSIMs de privacidade. Uma API quase pública existe no nível B2B dos marketplaces. O ponto é que um agente tem de passar em cada passo num fluxo contínuo — e uma corrente parte-se no seu elo mais fraco. Um fornecedor que acerta o pagamento mas força um registo falha. Um com uma ótima API mas um checkout só de cartão falha. Um que passa os primeiros quatro mas não tem tetos de gasto não deveria sequer ser ligado. A prontidão para agentes não é uma funcionalidade da qual se pode ter a maior parte; é a sequência inteira ou não é nada. Essa restrição de fluxo único é a razão pela qual o argumento a favor da conectividade como primeira compra de um agente assenta em fazer os cinco, não quatro.
Corre-o tu mesmo
As cinco perguntas são curtas de propósito. Aponta-as a qualquer fornecedor de eSIM — incluindo este — e em poucos minutos saberás se um agente consegue de facto comprar a partir dele: consegue ler o catálogo sem um browser, começar sem um registo, pagar sem um formulário de cartão, receber o eSIM como dados, e estar limitado por um modelo de segurança real? A maior parte do mercado responde não a três ou mais. Aqueles que respondem sim a todas as cinco valem o teu tempo de integração. Para veres como é um sim de ponta a ponta, o tutorial de configuração em cinco minutos percorre o fluxo inteiro, e agents.html é a visão geral de uma página.