Automatiza la verificación por SMS: guía completa de la API

La web es suficiente para un registro ocasional y puntual: unos clics y esperar un SMS. Deja de ser suficiente cuando escribes pruebas automatizadas, un script de registro masivo, un pipeline de CI o un bot que necesita obtener el código de verificación sin intervención humana. Eso la web no puede hacerlo. La API sí. Aquí tienes todo lo necesario para pasar de cero a un flujo que funciona.

Paso 1: consigue una clave de API

Inicia sesión y ve a /account/api-keys para crear una. Las claves tienen la forma jm_ seguido de una cadena aleatoria. El texto en claro se muestra exactamente una vez — nosotros guardamos un hash, no la clave en sí, así que no existe la opción "recuperar mi clave" si la pierdes. Bórrala y crea una nueva.

Cada petición usa autenticación Bearer estándar:

Authorization: Bearer jm_your_key

Trata la clave como una contraseña: no la subas a un repositorio público, no la pegues en un chat para que alguien te ayude a depurar. Si sospechas que se filtró, vuelve a /account/api-keys, bórrala y genera una nueva; la anterior deja de funcionar de inmediato.

Paso 2: elige un servicio y un país

Para hacer un pedido necesitas dos cosas: service (un código de servicio) y country (un id de país). Empieza por listar el catálogo:

curl https://jiema.my/api/v1/services \
  -H "Authorization: Bearer jm_your_key"

Cada elemento tiene un campo code (el de Telegram es tg) — pásalo directamente al endpoint de pedidos, es más fiable que reconstruir un slug tú mismo. Para ver precios y stock en tiempo real de un servicio concreto en todos los países, añade el parámetro service:

curl "https://jiema.my/api/v1/prices?service=tg" \
  -H "Authorization: Bearer jm_your_key"

Cada entrada de items tiene countryId / priceCents / count (los números disponibles en este momento). Comprueba count antes de pedir — si es cero, el pedido va a fallar, así que no gastes una llamada solo para descubrirlo por las malas.

Paso 3: haz el pedido

curl -X POST https://jiema.my/api/v1/orders \
  -H "Authorization: Bearer jm_your_key" \
  -H "Content-Type: application/json" \
  -d '{"service":"tg","country":"6"}'

Un pedido correcto devuelve un número de teléfono y una fecha de expiración:

{
  "ok": true,
  "data": {
    "id": "cm...",
    "status": "WAITING",
    "phone": "62812xxxxxxx",
    "expiresAt": "2026-08-01T12:15:00.000Z",
    "chargedCents": "40"
  }
}

El cobro ocurre en este paso — chargedCents es lo que realmente se descontó (en centavos). Entrega ese número a la app de destino para recibir el código de verificación y luego pasa al siguiente paso.

Paso 4: haz polling hasta obtener el código

No hay WebSocket ni webhook — el contenido del SMS se obtiene consultando GET /api/v1/orders/:id hasta que smsBody deje de ser null:

while true; do
  RESP=$(curl -s https://jiema.my/api/v1/orders/$ORDER_ID \
    -H "Authorization: Bearer jm_your_key")
  BODY=$(echo "$RESP" | jq -r '.data.smsBody')
  if [ "$BODY" != "null" ]; then
    echo "Code received: $BODY"
    break
  fi
  sleep 5
done

Cinco segundos es un punto de partida razonable — el número es válido durante 15 minutos, y el límite de 60 peticiones de consulta por minuto deja mucho margen. Tres segundos también funcionan si no tienes paciencia; consultar una vez por segundo no consigue el código más rápido, solo agota tu límite de peticiones.

Trampas

• Los límites de peticiones son por usuario, no por clave. Los endpoints de escritura (order / cancel / next-sms) están limitados a 10 por minuto por usuario; las consultas, a 60 por minuto. Crear más claves no te da un límite más alto — todas comparten el mismo.
• Los números expiran a los 15 minutos. Un número sin usar que expira sin recibir un código se reembolsa automáticamente, no hace falta pedirlo. Pero si tu propio pipeline retiene el número demasiado tiempo antes de usarlo de verdad (atascado en una cola, por ejemplo), estará muerto para cuando llegues a usarlo.
• Un número puede recibir más de un código. Si la app de destino envía el SMS en dos pasos (una confirmación de registro y luego un código de inicio de sesión aparte), llama a POST /api/v1/orders/:id/next-sms después de que llegue el primero para decirnos "con este ya terminé, sigue escuchando" — no hace falta hacer un pedido nuevo para obtener un número nuevo.
• Una vez que llega un código, cancelar deja de funcionar. POST /api/v1/orders/:id/cancel reembolsa al instante mientras el número todavía espera un código. Una vez que smsBody ha dejado de ser nulo alguna vez, esa misma llamada devuelve en su lugar un error CODE_RECEIVED — ya recibiste lo que pagaste, así que no hay vuelta atrás.
• No te quedes con una sola consulta de estado y te rindas. status pasa de WAITING a RECEIVED. Si se queda en WAITING hasta expirar, normalmente es un problema de tasa de entrega para esa combinación concreta de país/servicio — hacer un pedido nuevo en otro país suele resolverlo más rápido que esperar.

Próximos pasos

Eso cubre el flujo principal, de pedido a código. La lista completa de campos, códigos de error y casos límite de cada endpoint está en /api-docs. Si operas a gran escala — por ejemplo, manteniendo activos los flujos de verificación de docenas de cuentas a la vez — cronometra el bucle de consulta de cada pedido de forma independiente. No los pongas en cola dentro de un único bucle secuencial, o los números más antiguos expirarán mientras sigues esperando el primero.