Documentación de la API
Introducción
La API de Verificar CURP trabaja en dos pasos. El paso 1 valida el formato de la CURP y la coteja contra los datos que ya tienes de la persona, y responde al instante. El paso 2, opcional, verifica la CURP en el registro de RENAPO y te entrega el resultado en tu destino, normalmente en segundos. Los dos pasos consumen 1 token.
URL Base: https://verificarcurp.com/api/v1
Para agentes de IA: /llms.txt es el índice del servicio y /llms-full.txt contiene endpoints, campos, precios y preguntas frecuentes en un solo archivo de texto.
Obtén tu API key
Crea tu cuenta aquí mismo, sin salir de esta página, y genera tu API key en menos de un minuto.
20 tokens gratis al crear tu cuenta: suficientes para probar la API con tus propios documentos antes de comprar el primer paquete.
¿Ya tienes cuenta? Ve a tus API keys.
Autenticación
Todas las peticiones a la API requieren autenticación mediante una API key. Incluye tu API key en el header X-API-Key de cada petición.
curl https://verificarcurp.com/api/v1/balance \ -H "X-API-Key: curp_tu_api_key"
Puedes generar y administrar tus API keys desde el dashboard.
Endpoints
/api/v1/curpValida una CURP, coteja los datos de la persona si los envías y, con verificar, la consulta en el registro de RENAPO.
El objeto persona es opcional: sin él la respuesta es sólo la validación. Cada campo que mandas se coteja por separado, y un campo cuya comparación dependería de las reglas internas con que RENAPO forma la CURP —que no son públicas— responde indeterminado en lugar de adivinar.
Ejemplo
curl -X POST https://verificarcurp.com/api/v1/curp \
-H "X-API-Key: curp_tu_api_key" \
-H "Content-Type: application/json" \
-d '{
"curp": "PEGJ850101HDFRRL04",
"persona": {
"nombres": "JULIO",
"primerApellido": "PEREZ",
"segundoApellido": "GARZA",
"fechaNacimiento": "1985-01-01",
"sexo": "H",
"entidad": "CDMX"
}
}'Respuesta
{
"success": true,
"data": {
"curp": "PEGJ850101HDFRRL04",
"valida": true,
"razon": null,
"fechaNacimiento": "1985-01-01",
"sexo": "H",
"claveEntidad": "DF",
"entidad": "Ciudad de México",
"cotejo": "coincide",
"cotejoCampos": {
"nombres": "coincide",
"primerApellido": "coincide",
"segundoApellido": "coincide",
"fechaNacimiento": "coincide",
"sexo": "coincide",
"entidad": "coincide"
}
},
"tokens_remaining": 19
}/api/v1/curpcon verificación en el registro de RENAPOEl paso 2. Agrega verificar: true a la misma llamada y consultamos la CURP en el registro de RENAPO: si existe, su estatus y los datos con que está registrada. La respuesta del paso 1 llega al instante, como siempre; el resultado del registro llega a tu destino por separado, normalmente en segundos. Va incluida en el mismo token.
La petición
destinationId es obligatorio con verificar: es a donde llega el resultado (un webhook, un correo o un chat que configuras en el panel, en Destinos). Un destino que no existe o no es tuyo responde 400 DESTINATION_NOT_FOUND, antes de cobrar nada. idempotencyKey es opcional, lo eliges tú (nunca pongas la CURP en él) y viaja de vuelta en la entrega.
curl -X POST https://verificarcurp.com/api/v1/curp \
-H "X-API-Key: curp_tu_api_key" \
-H "Content-Type: application/json" \
-d '{
"curp": "PEGJ850101HDFRRL04",
"verificar": true,
"destinationId": "dst_...",
"idempotencyKey": "opcional"
}'Garantizamos la verificación: reintentos
Si el registro no responde, reintentamos la consulta automáticamente y, si los reintentos se agotan, una persona de nuestro equipo resuelve la verificación a mano. De forma predeterminada son 3 intentos en total y el primer reintento llega a los 5 minutos; la espera se duplica en cada intento, y los reintentos automáticos nunca duran más de 24 horas. Cada intento usa una fuente de consulta distinta: si hay otra disponible, el siguiente intento sale de inmediato, y nunca hacemos más intentos que fuentes disponibles, así que max es un tope, no una promesa. Tu cuenta guarda sus propios valores en Configuración, y reintentos los cambia para una sola petición: activo (verdadero o falso), max (intentos en total, de 1 a 5) y espera_s (segundos antes del primer reintento, de 60 a 3600). Cada campo es opcional; un valor fuera de rango se ajusta al límite y uno de tipo incorrecto se ignora, nunca es un 400. Con activo: false no hay reintentos automáticos: la verificación pasa directo a revisión manual.
{
"curp": "PEGJ850101HDFRRL04",
"verificar": true,
"destinationId": "dst_...",
"reintentos": { "activo": true, "max": 3, "espera_s": 300 }
}Los reintentos que se aplicaron
La respuesta inmediata repite, en verificacion.reintentos, los valores que quedaron fijados para esta verificación —los de tu cuenta con los de la petición encima, ya ajustados a sus límites—. Cambiar la configuración después no los altera.
"verificacion": {
"aceptada": true,
"job_id": "clz...",
"estado": "pendiente",
"expires_at": "...",
"reintentos": { "activo": true, "max": 3, "espera_s": 300 }
}La respuesta inmediata
data es la validación y el cotejo de siempre, sin cambios. verificacion es una clave hermana que dice si la consulta al registro quedó en curso y hasta cuándo puede tardar.
200 OK
{
"success": true,
"data": { ...validación y cotejo, sin cambios... },
"tokens_remaining": 431,
"verificacion": {
"aceptada": true,
"job_id": "clz...",
"estado": "pendiente",
"expires_at": "2026-09-29T16:35:00.000Z"
}
}Repetir una petición: idempotencyKey
Si repites la llamada con el mismo idempotencyKey desde la misma cuenta (por ejemplo, porque se cortó la conexión), no se crea otra verificación ni se cobra otro token: la respuesta trae el mismo job_id, su estado actual (pendiente si aún no empieza; después el del panel: running, retry-wait, delivered...) y repetida: true. tokens_remaining es tu saldo actual. La misma clave en otra cuenta no tiene relación con la tuya. Si la clave ya se usó en tu cuenta para otra CURP, la respuesta es 409 IDEMPOTENCY_KEY_REUSED, sin cobro y sin verificación. Solo podemos comparar la CURP mientras la tenemos (hasta que el resultado se entrega): después, repetir la clave devuelve la misma verificación sin compararla, así que usa una clave nueva para cada consulta. Una verificación que no se aceptó (aceptada: false) no reserva la clave. La clave vale mientras existe el registro de la verificación: 7 días.
200 OK
{
"success": true,
"data": { ...validación y cotejo, sin cambios... },
"tokens_remaining": 431,
"verificacion": {
"aceptada": true,
"job_id": "clz...",
"estado": "pendiente",
"expires_at": "2026-09-29T16:35:00.000Z",
"repetida": true
}
}Cuando no se puede verificar
La llamada sigue siendo 200: la validación y el cotejo ya están en data. verificacion trae aceptada: false y un código: REGISTRY_UNAVAILABLE (el registro no está disponible ahora), REGISTRY_CEILING_REACHED (límite diario de consultas alcanzado), TOO_MANY_VERIFICATIONS (demasiadas verificaciones en curso, o demasiadas seguidas sin entregar, en tu cuenta) o CURP_MALFORMED (la CURP no tiene 18 caracteres o lleva una letra donde va un número, o al revés: el registro no la acepta, así que no se consulta). retry_after trae segundos cuando vale la pena reintentar, y la respuesta lleva el mismo valor en el encabezado Retry-After: con REGISTRY_UNAVAILABLE es cuándo volvemos a probar el registro; con REGISTRY_CEILING_REACHED, cuándo se reinicia el límite diario (medianoche UTC). Es null, sin encabezado, cuando esperar no ayudaría. Salvo con CURP_MALFORMED, la llamada no se cobra: no te cobramos una verificación que no corrimos, y tokens_remaining no cambia.
200 OK
Retry-After: 240
"verificacion": {
"aceptada": false,
"codigo": "REGISTRY_UNAVAILABLE",
"retry_after": 240
}Lo que llega a tu destino
Un sobre firmado (X-Signature, HMAC con el secreto del destino). El evento es curp.verification.completed cuando el registro respondió —incluido estatus: "NO_ENCONTRADA"— o curp.verification.failed cuando no obtuvimos respuesta y dejamos de intentarlo. Cada aviso se entrega una sola vez: no reintentamos la entrega a tu destino, así que asegúrate de que esté respondiendo.
POST <tu endpoint>
X-Signature: <hmac>
X-Signature-Timestamp: <unix>
X-Idempotency-Key: <la tuya, o la del trabajo>
{
"version": "1",
"event": "curp.verification.completed",
"documentType": "curp",
"extractedAt": "2026-09-29T16:31:12.000Z",
"data": {
"estatus": "ACTIVA",
"curp": "PEGJ850101HDFRRL04",
"estatusCodigo": "AN",
"estatusDescripcion": "Alta normal",
"nombres": "...", "primerApellido": "...", "segundoApellido": "...",
"fechaNacimiento": "...", "sexo": "...",
"entidadNacimiento": "...", "nacionalidad": "...",
"documentoProbatorio": "..."
}
}Consultar el estado: GET /api/v1/curp/verificacion/{job_id}
Con tu API key y sin costo, trae el estado de la verificación (estado, intentos, entrega_ok…). Si el resultado del registro sigue guardado, lo trae en valores una sola vez y lo borra en la misma operación. Cuando la entrega a tu destino tuvo éxito, el resultado ya se borró y aquí solo verás el estado; si tu destino falló, esta es la forma de recuperarlo. Una verificación que no es de tu cuenta responde 404 NOT_FOUND.
curl https://verificarcurp.com/api/v1/curp/verificacion/clz... \ -H "X-API-Key: curp_tu_api_key"
Avisos mientras reintentamos
curp.verification.retrying llega a tu destino después de cada intento fallido que tiene otro programado: qué intento fue, de cuántos, por qué falló, cuándo será el siguiente (retry_in_seconds en 0 si sale de inmediato por otra fuente) y hasta cuándo seguiremos reintentando. Es un aviso de avance, no el resultado, y nunca trae la CURP. Todos los valores de data son texto.
{
"version": "1",
"event": "curp.verification.retrying",
"documentType": "curp",
"data": {
"job_id": "clz...",
"attempt": "1",
"max_attempts": "3",
"error_code": "REGISTRY_UNAVAILABLE",
"next_attempt_at": "2026-09-29T16:36:12.000Z",
"retry_in_seconds": "300",
"retry_deadline_at": "2026-09-30T16:31:00.000Z",
"idempotency_key": "opcional"
}
}Cuando pasa a revisión manual
curp.verification.manual_review avisa que la verificación salió de los reintentos automáticos y una persona de nuestro equipo la tiene: hasta que se resuelva, sin plazo fijo. reason dice por qué: exhausted (se agotaron los intentos), not-retryable (la falla no se arregla reintentando), disabled (reintentos apagados), window (pasaron 24 horas), user-cap (demasiadas verificaciones de tu cuenta esperando reintento) o settings-changed (cambiaste la configuración de reintentos mientras esperaba). El resultado llega después como curp.verification.completed, o como curp.verification.failed solo si, excepcionalmente, no logramos resolverla.
{
"version": "1",
"event": "curp.verification.manual_review",
"documentType": "curp",
"data": {
"job_id": "clz...",
"reason": "exhausted",
"idempotency_key": "opcional"
}
}El estado en el panel
En Validar CURP, el panel sigue cada verificación con estos campos: estado (retry-wait mientras espera el siguiente intento, needs-human en revisión manual), intentos y max_intentos, proximo_intento_en, reintentos_hasta, ultimo_codigo (el código del último intento fallido) y revision_manual (el mismo reason del aviso, o null). Desde tu integración, los mismos campos llegan con tu API key en GET /api/v1/curp/verificacion/{job_id}, descrito arriba.
Qué se cobra
Nada adicional. La verificación va incluida en el token de la llamada, que se cobra por la validación y el cotejo como siempre. Si pediste la verificación y no la aceptamos por un límite nuestro (cualquier código menos CURP_MALFORMED), la llamada no se cobra. Si el registro no responde (curp.verification.failed), no se cobra nada más. Los reintentos y la resolución a mano tampoco se cobran: son parte de la misma verificación.
Qué se guarda, y por cuánto
La CURP se guarda mientras se consulta el registro y se borra al terminar. Si el registro no responde, se conserva mientras reintentamos —a lo sumo 24 horas— y, si la verificación pasa a revisión manual, hasta que se resuelva: una persona de nuestro equipo la ve solo para resolverla. El resultado se borra en cuanto se entrega, y nunca se conserva más de una hora. Después queda, durante 7 días, un registro de cuándo se pidió y cómo terminó, nunca qué se consultó. Los datos del cotejo nunca se envían al registro.
/api/v1/curp/calcularCalcula la CURP a partir de los datos de la persona: nombres, apellidos, fecha de nacimiento, sexo y entidad de nacimiento. Se calcula al instante con las reglas publicadas de RENAPO, sin consultar el registro. Consume 1 token.
Las posiciones 1 a 16 salen de los datos. La 17 (el diferenciador de la homoclave) la asigna RENAPO para distinguir homónimos y no se puede deducir: asumimos 0 para nacidos antes de 2000 y A desde 2000, que es lo que el registro asigna cuando no hay homónimo, y la respuesta lo indica con diferenciadorAsumido. El dígito verificador se calcula sobre esa suposición. Para confirmar que la CURP existe, verifícala con POST /api/v1/curp.
segundoApellido es opcional: omitido o null significa que la persona no tiene segundo apellido. Si falta un campo obligatorio o uno no se puede convertir en caracteres de la CURP (una fecha que no existe, un sexo distinto de H/M, una entidad ambigua como «México»), la petición se rechaza con 400 INVALID_REQUEST, el campo en field, y no consume token.
Ejemplo
curl -X POST https://verificarcurp.com/api/v1/curp/calcular \
-H "X-API-Key: curp_tu_api_key" \
-H "Content-Type: application/json" \
-d '{
"nombres": "JUAN",
"primerApellido": "PEREZ",
"segundoApellido": "GOMEZ",
"fechaNacimiento": "1985-01-01",
"sexo": "H",
"entidad": "CDMX"
}'Respuesta
{
"success": true,
"data": {
"curp": "PEGJ850101HDFRMN02",
"raiz": "PEGJ850101HDFRMN",
"diferenciador": "0",
"diferenciadorAsumido": true,
"digitoVerificador": "2",
"fechaNacimiento": "1985-01-01",
"sexo": "H",
"claveEntidad": "DF",
"entidad": "Ciudad de México"
},
"tokens_remaining": 431
}/api/v1/rfc/calcularCalcula el RFC con homoclave de una persona física a partir de sus nombres, apellidos y fecha de nacimiento. Se calcula al instante con el algoritmo publicado del SAT, sin consultar al SAT. Consume 1 token.
Las posiciones 1 a 10 salen del nombre y la fecha. La homoclave (posiciones 11 y 12) y el dígito verificador se calculan con las tablas del SAT sobre el nombre completo, pero el SAT asigna otra homoclave cuando dos contribuyentes coinciden o si tiene el nombre registrado de otra forma; la respuesta lo indica con homoclaveAsumida. Un RFC calculado no confirma que la persona esté inscrita en el SAT.
segundoApellido es opcional: omitido o null significa que la persona no tiene segundo apellido. En lugar de fechaNacimiento puedes mandar curp y tomamos la fecha de ahí (solo la fecha). Si mandas las dos, deben coincidir. Si falta un campo obligatorio o uno no se puede convertir en caracteres del RFC (un nombre sin letras, una fecha que no existe, una CURP inválida o cuya fecha no coincide), la petición se rechaza con 400 INVALID_REQUEST, el campo en field, y no consume token.
Modo solo CURP: si mandas curp y destinationId sin nombres ni primerApellido, primero consultamos en RENAPO el nombre registrado para esa CURP y calculamos el RFC con él. La respuesta es 202 con data: null y verificacion.job_id; el RFC llega a tu destino en el evento curp.verification.* (producto: "calculo-rfc", rfc, rfcRaiz, rfcHomoclave, rfcDigitoVerificador) y en GET /api/v1/curp/verificacion/{job_id} como rfc. Cuesta 1 token, igual que una verificación, y se reembolsa (reembolsado: "true") si la CURP no se encuentra, el registro no devuelve nombre o la consulta no termina. Si no podemos consultar el registro en ese momento, responde 503 sin cobrar.
Ejemplo
curl -X POST https://verificarcurp.com/api/v1/rfc/calcular \
-H "X-API-Key: curp_tu_api_key" \
-H "Content-Type: application/json" \
-d '{
"nombres": "EMMA",
"primerApellido": "GOMEZ",
"segundoApellido": "DIAZ",
"fechaNacimiento": "1956-12-31"
}'Respuesta
{
"success": true,
"data": {
"rfc": "GODE561231GR8",
"raiz": "GODE561231",
"homoclave": "GR",
"homoclaveAsumida": true,
"digitoVerificador": "8",
"fechaNacimiento": "1956-12-31"
},
"tokens_remaining": 431
}/api/v1/balanceObtiene el saldo actual de tokens de tu cuenta.
Ejemplo
curl https://verificarcurp.com/api/v1/balance \ -H "X-API-Key: curp_tu_api_key"
Respuesta
{
"success": true,
"balance": 20
}SDKs oficiales
Validación, cotejo, verificación en RENAPO y la firma de tus webhooks, con tipos y sin dependencias.
JavaScript / TypeScript
npm install verificar-curp
import { VerificarCurpClient } from 'verificar-curp'
const client = new VerificarCurpClient({ apiKey: 'curp_tu_api_key' })
const { data } = await client.validate({
curp: 'PEGJ850101HDFRRL04',
persona: { nombres: 'Julio', fechaNacimiento: '1985-01-01', sexo: 'H' },
})
console.log(data.valida, data.cotejo)
// Verificación en RENAPO: el resultado llega a tu destino
const { verificacion } = await client.validate({
curp: 'PEGJ850101HDFRRL04',
verificar: true,
destinationId: 'dst_...',
})
// Webhook: verifica la firma con el cuerpo crudo
import { parseWebhook } from 'verificar-curp'
const event = await parseWebhook({ secret, rawBody, signature, timestamp })Código fuente y documentación completa en GitHub · npm.
Python
pip install verificar-curp
from verificar_curp import VerificarCurpClient
client = VerificarCurpClient(api_key="curp_tu_api_key")
result = client.validate(
"PEGJ850101HDFRRL04",
persona={"nombres": "Julio", "fechaNacimiento": "1985-01-01", "sexo": "H"},
)
print(result.data["valida"], result.data["cotejo"])Código fuente y documentación completa en GitHub · PyPI.
Servidor MCP (Claude, Cursor)
Valida y verifica CURPs desde tu asistente de IA. Agrégalo a la configuración MCP de tu cliente:
{
"mcpServers": {
"verificar-curp": {
"command": "npx",
"args": ["-y", "verificar-curp-mcp"],
"env": { "VERIFICAR_CURP_API_KEY": "curp_tu_api_key" }
}
}
}Enlaces de captura y webhooks
Mándale a tu huésped o cliente un enlace de un solo uso: escribe su CURP desde su celular, la validamos y la cotejamos al instante, y el resultado llega a tu destino (webhook, correo o Telegram). Si tienes los datos de la reservación, mándalos en persona y también se cotejan contra ellos. Disponible para todas las cuentas (beta). Los destinos se configuran en el panel, en Destinos.
/api/v1/capture-linkscurl -X POST https://verificarcurp.com/api/v1/capture-links \
-H "X-API-Key: curp_tu_api_key" \
-H "Content-Type: application/json" \
-d '{
"destinationId": "<id de tu destino>",
"reference": "reserva-8841",
"persona": {
"nombres": "Julio",
"primerApellido": "Pérez",
"fechaNacimiento": "1985-01-01"
}
}'destinationIdes requerido.persona(opcional) son los datos de la reservación: si la CURP no coincide, a tu cliente se le pide acudir a recepción, sin mostrarle tus datos. ConaskGuestPersona: truetu cliente también escribe su nombre, primer apellido y fecha de nacimiento.reference(hasta 80 caracteres) viaja en la entrega.- Un solo uso: 15 minutos para abrirlo y, ya abierto, 15 minutos para responder.
- La url solo se devuelve en esta respuesta; trátala como una credencial y no la guardes en logs.
- Crear el enlace no cuesta. Cada respuesta cuesta 1 token, también un
no_coincide, igual que enPOST /api/v1/curp. El enlace admite 3 intentos, así que un cliente que se equivoca puede costar hasta 3 tokens. Si la entrega falla, el token se devuelve. - Solo una CURP válida y que coincide llega a tu destino. Hasta 20 enlaces vivos a la vez (400 TOO_MANY_LIVE_LINKS); un destino inexistente o pausado: 400 DESTINATION_NOT_FOUND.
Respuesta (201)
{
"success": true,
"id": "clx_enlace_456",
"url": "https://verificarcurp.com/c/…",
"reference": "reserva-8841",
"documentType": null,
"requireBack": false,
"askGuestPersona": false,
"expiresAt": "2026-09-30T18:15:00.000Z"
}Webhooks: lo que recibe tu servidor
Cada entrega a un destino de tipo webhook, ya sea de un enlace de captura o de una verificación en RENAPO, es un POST firmado. Se intenta una sola vez, sin seguir redirecciones y con 10 segundos de espera; responde 2xx.
POST /tu-webhook
Content-Type: application/json
X-Signature: sha256=5f2b…
X-Signature-Timestamp: 1790000000
X-Idempotency-Key: 3f6c1d9e-5b7a-4c2e-9a41-0d8e7f6b2c10
{
"version": "1",
"event": "extraction.completed",
"idempotencyKey": "3f6c1d9e-5b7a-4c2e-9a41-0d8e7f6b2c10",
"documentType": "curp",
"source": "capture-link",
"captureLinkId": "clx_enlace_456",
"reference": "reserva-8841",
"extractedAt": "2026-09-30T18:05:02.000Z",
"data": {
"curp": "PEGJ850101HDFRRL04",
"valida": "true",
"fecha_nacimiento": "1985-01-01",
"sexo": "H",
"clave_entidad": "DF",
"entidad": "Ciudad de México",
"cotejo_reserva": "coincide",
"cotejo_reserva_nombres": "coincide",
"cotejo_reserva_primer_apellido": "coincide",
"cotejo_reserva_fecha_nacimiento": "coincide"
}
}Los valores de data son texto. cotejo y cotejo_<campo> llegan si tu cliente escribió sus datos; cotejo_reserva y cotejo_reserva_<campo>, si mandaste persona. Usa X-Idempotency-Key para descartar duplicados.
Firma: X-Signature es sha256= más el HMAC-SHA256 en hexadecimal, con el secreto del destino (whsec_…), de X-Signature-Timestamp + "." + el cuerpo crudo. Verifica sobre los bytes recibidos (no sobre el JSON re-serializado), compara en tiempo constante y rechaza timestamps de más de 5 minutos. Los SDKs oficiales lo hacen por ti.
import { createHmac, timingSafeEqual } from 'node:crypto'
function verify(secret, rawBody, signature, timestamp) {
if (Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return false
const expected = 'sha256=' + createHmac('sha256', secret)
.update(`${timestamp}.${rawBody}`)
.digest('hex')
const a = Buffer.from(expected)
const b = Buffer.from(signature ?? '')
return a.length === b.length && timingSafeEqual(a, b)
}Códigos de error
| Código | HTTP | Descripción |
|---|---|---|
MISSING_API_KEY | 401 | No se proporcionó API key |
INVALID_API_KEY | 401 | API key inválida o revocada |
INVALID_REQUEST | 400 | El cuerpo de la petición no tiene la forma esperada; no consume token |
INSUFFICIENT_TOKENS | 402 | Saldo insuficiente de tokens |
INTERNAL_ERROR | 500 | Error interno del servidor |
Campos
La respuesta devuelve los siguientes campos:
curpLa CURP que enviaste, normalizada a mayúsculas
validaSi la CURP está bien formada
razonPor qué no es válida, cuando no lo es
fechaNacimientoFecha de nacimiento que codifica la CURP
sexoSexo que codifica la CURP (H o M)
claveEntidadClave de la entidad de nacimiento que codifica la CURP
entidadEntidad de nacimiento que codifica la CURP
cotejoResultado del cotejo: coincide, no_coincide o indeterminado
cotejoCamposResultado del cotejo campo por campo: nombres, apellidos, fecha, sexo y entidad
verificacionSi pediste la verificación en el registro de RENAPO: si se aceptó y su job_id. El resultado llega a tu destino
Límites y cuotas
- Cada respuesta consume 1 token, incluida una CURP mal formada y un cotejo que no coincide: la respuesta es el producto
- Cada CURP calculada con /api/v1/curp/calcular consume 1 token
- Cada RFC calculado con /api/v1/rfc/calcular consume 1 token
- Una petición mal formada se rechaza con 400 y no consume token
- Si la respuesta falla por un error nuestro, el token se reembolsa automáticamente
- La verificación en el registro de RENAPO va incluida en el mismo token; si el registro no responde, no se cobra nada adicional
- La respuesta inmediata no devuelve datos personales que no hayas enviado; los datos del registro solo llegan, con la verificación, a tu destino
- Los tokens no expiran