Plan y consumo
Plan actual, funciones incluidas, límites y verificaciones consumidas en el mes. Sirve para que un bot pregunte «¿esta cuenta todavía puede verificar?» antes de pedirle la foto al cliente.
Autorización
apiKey plan.readLa llave del negocio, creada en el panel: Integraciones → API pública. Formato vk_live_… (o vk_test_… fuera de producción).
Va en: header
Permiso: plan.read
Cuerpo de la respuesta
application/json
application/json
application/json
curl -X GET "https://example.com/plan"{ "object": "plan", "key": "GROWTH", "name": "Crecimiento", "level": 20, "status": "ACTIVE", "features": { "public_api": true, "expenses_module": true, "whatsapp_bot": true }, "limits": { "limit_verifications": 4000, "limit_api_requests_per_minute": 120 }, "enums": { "report_frequency": "DAILY" }, "usage": { "verifications": { "used": 312, "limit": 4000, "remaining": 3688 } }}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.
Verificar un comprobante POST
Registra un comprobante y devuelve el veredicto. Pasa por la misma cadena que el bot propio de Verifika: candado de la cuenta → plan → cupo → duplicado → cruce con el aviso del banco. Consume una verificación del cupo mensual salvo que resulte duplicado. El pago nace PENDING, nunca VERIFIED: solo el cruce con el aviso real del banco puede confirmarlo. Si el banco ya había avisado, el cruce ocurre en esta misma llamada y el ingreso vuelve verificado.