Referencia de la API
Cada endpoint con sus parámetros, sus respuestas y un playground para probarlo.
Todo cuelga de https://api.verifika.tech/v1 y va con la llave en la cabecera:
Authorization: Bearer vk_live_...Puedes probar desde aquí
Cada endpoint trae un playground. Pega tu llave y ejecútalo contra tus propios datos — con una llave de solo lectura no hay nada que se pueda romper.
Identidad
Quién es la llave, qué plan y cuánto cupo queda.
Verificar
¿Este comprobante es real? El endpoint central.
Ingresos
Leer, declarar, corregir y eliminar pagos.
Egresos
Gastos y sus categorías.
Negocio
Datos del negocio, sucursales y cuentas de recaudo.
Equipo
Quién trabaja aquí, con qué rol y en qué sucursal.
Pagos sospechosos
Comprobantes repetidos y no respaldados.
Bancos
Si los avisos del banco siguen entrando.
Reportes
Totales, series, turnos y rankings.
Webhooks
Suscribirte a eventos y ver el historial de entregas.
Los dos endpoints que se confunden
Es la distinción más importante de toda la API, y equivocarse cuesta cupo o credibilidad del dato:
POST /v1/verifications | POST /v1/incomes | |
|---|---|---|
| Qué le estás pidiendo | «¿este pago entró de verdad?» | «anota que entró esta plata» |
| Estado en que nace | PENDING → VERIFIED si el banco confirma | DECLARED |
| ¿Consume cupo? | Sí, una verificación | No |
| ¿Se puede editar después? | No, es inmutable | Sí |
| Para qué sirve | Un bot que recibe comprobantes | Un ERP que sincroniza sus ventas |
Lo que aplica a todos
| Autenticación | Authorization: Bearer vk_live_… |
| Negocio | ?companyId= — obligatorio solo si la llave entra a varios |
| Paginación | ?limit= y ?startingAfter= — ver guía |
| Escrituras | Idempotency-Key — ver guía |
| Montos | Enteros en pesos: 45000 = $45.000 |
| Fechas | ISO 8601 en UTC |
| Errores | { error: { code, message, details?, requestId } } — catálogo |
Verifica desde tu propio bot
Cómo un bot de WhatsApp ajeno valida comprobantes con Verifika por dentro.
Quién soy GET
Valida la llave y devuelve a qué negocios entra, qué permisos tiene y en qué plan está la cuenta. Es el request que conviene hacer primero en cualquier integración: si algo va a fallar por configuración, falla aquí y no a mitad del flujo.