​
Filtrado de listados

Todos los GET de listado aceptan el mismo formato (documentación del propio gateway):
Ejemplo real:

​
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. Todo verificado en el código del servicio. 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. Sin reintentos, un pico de carga o un deploy tuyo pierde avisos definitivamente. Hace falta un polling de respaldo con updatedAt[gte] sobre la última fecha que procesaste.
  3. Deduplicá por comprobante, no por aviso. Dos avisos pueden traer rangos solapados; lo estable es el id del CFE y su estado.
  4. Respondé rápido y con 2xx. No hay reintento que te salve de un timeout, y el gateway no espera nada del cuerpo de tu respuesta.
La falta de firma y la falta de validación TLS están registradas como hallazgos para pymo, no son recomendaciones de diseño de esta documentación.