Registro de cambios

Nuestra política de versionado: los campos y endpoints nuevos son aditivos y nunca cuentan como un cambio incompatible bajo el prefijo /api/v1/ — eliminar o cambiar el significado de un campo existente sería una v2. Eso significa que puedes tratar cada entrada de abajo como "esto es lo nuevo", no como "esto podría romper tu integración".

2026-09-26

• format_requirement en fields ad-hoc ahora se aplica. Cuando se llamaba a POST /batches/{batch_name}/process con fields (sin template_id), el format_requirement de cada campo se descartaba antes de la extracción, por lo que los valores volvían tal como estaban impresos en el documento. Ahora llegan al modelo y tienen prioridad sobre cualquier plantilla con la que se subieran los documentos. Las plantillas guardadas no se vieron afectadas. Consulta la referencia de Batches.
• POST /documents rechaza un batch_name de más de 50 caracteres con 400 invalid_parameter. Antes, esos nombres fallaban con un 500 o con un "Failed to render PDF." engañoso en las subidas de PDF.

2026-09-14

• Se agregó PUT /templates/{id}/settings. Establece el requisito de formato global de una plantilla y la configuración de fusión de varias páginas (si varias páginas subidas que pertenecen al mismo registro — un contrato de arrendamiento de varias páginas, un paquete de recibos grapados — deben combinarse en una sola fila de salida). El objeto Template devuelto por cada endpoint de plantillas ahora también incluye global_format_requirement y todos los campos merge_*. Consulta la referencia de Templates & Fields.
• GET /batches/{batch_name}/results ahora admite ?merge=true. Aplica la configuración de fusión de varias páginas de la plantilla resuelta del lote, si tiene una — los documentos que se combinan en un registro fusionado llevan un nuevo campo source_document_ids junto al habitual document_id, y la respuesta gana un campo de nivel superior merge_active. El valor predeterminado sigue siendo false: este endpoint es anterior a la fusión de varias páginas, por lo que las integraciones existentes siguen viendo una entrada por documento subido a menos que opten explícitamente. No se puede combinar con include=bbox. GET /batches/{batch_name}/export ya aplicaba la fusión incondicionalmente antes de este cambio y no se ve afectado. Consulta la referencia de Batches.
• El nivel de modelo ahora se refleja correctamente en la contabilidad de créditos para POST /batches/{batch_name}/process. Una cuenta asignada a Advanced o Premium (3x/6x el costo de crédito estándar por documento) ahora tiene esa tarifa aplicada de manera consistente tanto a la deducción al momento del procesamiento como a cualquier reembolso posterior por un documento cancelado o fallido — anteriormente, un documento cuya fila ImageUpload ya se había eliminado cuando se ejecutaba un reembolso podía volver a reembolsarse a la tarifa estándar, reembolsando de menos a una cuenta no estándar. Las entradas de GET /account/usage para una deducción/reembolso no estándar ahora llevan una action con sufijo de nivel (deduction_advanced, deduction_premium) en lugar del nombre simple. El nivel de modelo en sí no es nuevo, y todavía no hay forma a nivel de solicitud de seleccionarlo o anularlo — esta entrada trata sobre que la contabilidad ahora sea correcta y visible, no una nueva capacidad. Consulta la guía de Configuración de Account & Comportamiento de la API y la referencia de Account.

2026-08-04

• Se añadió GET /events para integraciones de sondeo. El feed de eventos devuelve eventos batch.completed, document.completed y document.failed del más reciente al más antiguo, con IDs de evento estables para la deduplicación estilo Zapier. Consulta la referencia de Webhooks.

2026-07-22

• POST /templates ahora aplica un límite de 30 plantillas por cuenta. Cuando llegues al límite, crear otra plantilla (desde cero o desde un preset) devuelve 400 template_limit_reached — elimina primero una plantilla existente. Este límite no se aplicaba antes. Consulta la referencia de Templates & Fields.

2026-07-21

• POST /documents ahora acepta archivos de Word (.docx) y texto plano (.txt), no solo imágenes y PDFs. Ambos se convierten a PDF en el servidor y luego siguen exactamente el mismo proceso de división por página que una subida de PDF nativa — un .docx de varias páginas produce un Document por página, igual que el comportamiento actual con PDF. El formato binario heredado .doc no es compatible; guarda como .docx primero. Consulta la referencia de Documents.
• El límite de páginas por subida sube de 30 a 50 páginas. Se aplica tanto a subidas de PDF nativas como a archivos .docx/.txt convertidos en el servidor. Consulta la referencia de Documents.
• GET /documents/{document_id}/image ahora admite ?size=thumb para una versión más pequeña y pregenerada de la imagen de página — más rápida de cargar en una vista de lista/cuadrícula que la página a resolución completa. Usa la imagen completa si no se generó una miniatura para ese documento (nunca es un error). Consulta la referencia de Documents.

2026-07-20

• Los webhooks de lote ahora se reactivan automáticamente al reprocesar un lote. Si subes más documentos a un lote que ya te notificó una vez y llamas a process de nuevo, recibirás otra notificación cuando esa nueva tanda termine — sin necesidad de volver a hacer PUT al webhook. Consulta la guía de Webhooks. Si tu integración actualmente vuelve a registrar el webhook antes de cada tanda como solución temporal, puedes dejar de hacerlo — esa llamada nunca reactivó nada en realidad.
• Los trabajos de anotación de bbox ahora entregan un evento de webhook. Un evento document.bbox_completed se dispara en el webhook del lote del documento cuando un trabajo de bbox alcanza un estado terminal — antes, las finalizaciones de bbox no producían ninguna notificación, sin importar el registro. Consulta la guía de Webhooks.
• remaining_batch_capacity añadido a las respuestas de POST /documents. Te indica cuántos documentos más puede aceptar este lote antes de alcanzar el tamaño máximo de lote de tu plan, sin necesidad de llamar por separado a GET /account.
• Las entregas de document.bbox_completed ahora se reclaman atómicamente, igual que batch.completed. Un trabajo de bbox cuyos grupos de filas terminan con momentos de diferencia entre sí en hilos distintos solía disparar a veces dos entregas separadas para lo que lógicamente era una sola finalización — ya no deberías ver eso. Si tu integración estaba deduplicando estos eventos por data.group_batch_id como solución temporal, no pasa nada por seguir haciéndolo.

2026-07-16

• API v1 lanzada. Publicación de /api/v1/, que cubre los recursos de Documents, Batches, Templates & Fields, Webhooks y Account para el modo de procesamiento table (extracción estructurada de campos). Consulta la Descripción general de la API para empezar.