​
Filtrado de listados

Todos los GET de listado aceptan el mismo formato:
Ejemplo:

​
Webhooks (notificaciones push)

El gateway avisa por POST cuando algo cambia. El aviso no trae los datos: trae la ruta a consultar, y el integrador hace un GET autenticado para obtenerlos.
url_to_check es una ruta, no una URL: hay que anteponerle la URL base del ambiente. Ya viene con el filtro updatedAt[gte] puesto, así que el GET devuelve exactamente lo que cambió desde el aviso anterior. Ese patrón es deliberado y conviene aprovecharlo: el aviso no está autenticado (ver abajo), así que no se le debe creer nada más que “andá a mirar”. Los datos llegan por el GET, que sí lleva tu sesión.

​
Cómo se configura

Es un campo de la sucursal, no de la empresa: callbackNotificationUrl en branchOffices[]. Cada sucursal puede tener la suya, o ninguna, y sin ella no se envía nada.
No se puede configurar por API. La actualización de sucursal aplica siete campos (contactNumber, name, fiscalAddress, city, state, from y until; estos dos últimos desactivan o reactivan la sucursal) y descarta el resto en silencio: mandar callbackNotificationUrl ahí responde éxito y no cambia nada. Se pide a pymo.

​
Tipos de notificación

  • CFE_STATUS_CHANGE - cambio de estado de un CFE (emitido o recibido)
  • NEW_REPORT - nuevo reporte diario enviado
  • INFO|WARNING|EMERGENCY|ERROR_SSLCERT_EXPIRE_IN_LESS_THAN_{30|15|7|0}_DAYS - vencimiento del certificado
  • INFO|WARNING|EMERGENCY|ERROR_CAE_NUMBER_EXPIRE_IN_LESS_THAN_{30|15|7|0}_DAYS - vencimiento de CAE
  • WARN_FEW_{cfeType}_CAE_NUMBERS - queda poca numeración para ese tipo
  • ERROR_NO_{cfeType}_CAE_NUMBERS - sin numeración para ese tipo

​
Garantías de entrega: cuáles hay y cuáles no

Esto es lo que hay que diseñar del lado del integrador, porque el gateway no lo resuelve. Consecuencias prácticas:
  1. Tratá el aviso como una señal, no como un dato. Cualquiera que conozca tu URL puede enviarte uno. Como el contenido real lo traés vos con un GET autenticado, un aviso falso te hace consultar de más y nada peor. No agregues lógica que dependa del body.
  2. No dependas de recibirlos todos. Tres intentos fallidos, por un pico de carga o un deploy tuyo, pierden el aviso definitivamente. Hace falta un polling de respaldo con updatedAt[gte] sobre la última fecha que procesaste.
  3. Deduplicá por comprobante, no por aviso. Un reintento repite el mismo aviso, y dos avisos pueden traer rangos solapados; lo estable es el id del CFE y su estado.
  4. Respondé con 2xx. Cualquier otro código cuenta como fallo y genera un reintento, así que el mismo aviso te llega otra vez. El gateway no espera nada del cuerpo de tu respuesta.
La falta de firma y la falta de validación TLS son propiedades del webhook tal como está hoy, no recomendaciones de diseño de esta documentación: integrá contra lo que la tabla de arriba dice que hay.