Integrar software agrícola con contabilidad: API y webhooks

TL;DR — resumen ejecutivo para el responsable de sistemas

• Una explotación grande o cooperativa maneja al menos tres sistemas a la vez: cuaderno de campo (SIEX), ERP contable y, con frecuencia, una báscula, un TPV de almacén o un módulo propio de facturación. Sin integración, los datos de cosecha, coste y factura se introducen dos o tres veces.
• La solución técnica son tres piezas: una API REST con tokens de alcance limitado (scoped) para leer y escribir datos desde el exterior, webhooks firmados con HMAC-SHA256 para recibir avisos en tiempo real cuando ocurre un hecho de dominio, y defensa anti-SSRF en el dispatcher que impide que el servidor llame a rangos de red privada o a destinos arbitrarios.
• El dato se anota una sola vez con rigor normativo (el cuaderno cumple RD 1054/2022; la factura cumple Verifactu/RRSIF) y fluye hacia el ERP contable o hacia cualquier sistema suscrito.
• Este artículo se dirige al responsable de sistemas de una cooperativa o explotación grande y al técnico integrador que conectará Campodato con el software externo. No es la guía técnica de la API (que tiene su propio artículo); el foco es el negocio: qué problema resuelve, qué flujos cubre y qué hay que tener en cuenta antes de integrar.

---

1. El problema real: islas de datos en la explotación grande

Una cooperativa vitivinícola con 300 socios trabaja, típicamente, con cuatro o cinco sistemas simultáneos: el cuaderno de campo digital que cada viticultor usa para anotar tratamientos fitosanitarios y riegos (obligación desde el 1-1-2026 para fertilización y desde el 1-1-2027 para tratamientos fitosanitarios electrónicos, según RD 1039/2025 al amparo del Reglamento UE 2025/2203), el libro de bodega con los registros SILICIE que controla la Agencia Tributaria, el software de facturación con encadenamiento Verifactu (RD 1007/2023), el ERP contable donde se recogen los costes de campaña y los gastos de insumos, y la báscula de recepción de cosecha que genera el albarán de entrada de uva.

Cuando esos sistemas no hablan entre sí, pasan tres cosas:

Primera: el dato se introduce dos o tres veces. El viticultor anota la cosecha en su cuaderno, el almacén la pesa en la báscula, el técnico de bodega la registra en SILICIE y el contable la asienta como ingreso. Son cuatro puntos de captura del mismo hecho, con cuatro posibilidades de error.

Segunda: las cifras no cuadran. La báscula redondea en kilogramos; el cuaderno usa toneladas; el albarán tiene una fecha diferente a la del SILICIE. Cuando la Agencia Tributaria cruza los datos de los libros de bodega con las facturas emitidas (la AEAT tiene acceso a los registros SILICIE conforme a la Orden HAC/998/2019 que regula el sistema), las discrepancias son costosas.

Tercera: la trazabilidad de costes es imposible en tiempo real. El responsable de sistemas no puede ver el margen de una campaña hasta que el contable cierra el mes o el trimestre, porque los costes de los tratamientos están en el cuaderno, los costes de mano de obra están en el software de fichaje y las facturas de insumos están en el ERP, sin conexión entre ellos.

La solución técnica, en todos estos casos, no es un ERP monolítico que absorba todo: es una capa de integración que permita que cada sistema especializado haga bien su trabajo y comparta los datos relevantes con los demás de forma automática y auditada.

---

2. Qué es una API REST y por qué es suficiente para la integración agraria

Una API REST (Representational State Transfer) es un conjunto de endpoints HTTP que permiten a un sistema externo leer y escribir datos en el sistema que la expone. El protocolo es el mismo que usa cualquier navegador web: peticiones HTTP con métodos estándar (GET para leer, POST para crear, PATCH para actualizar) y respuestas en formato JSON.

La ventaja de REST frente a soluciones propietarias (ficheros CSV que se intercambian por FTP, conexiones directas a bases de datos o integraciones punto a punto) es la desacoplación: el ERP contable no necesita saber cómo está construido internamente el cuaderno de campo. Solo necesita conocer los endpoints, los formatos de datos y las reglas de autenticación. Si el cuaderno cambia su base de datos o su arquitectura interna, la API REST no cambia y la integración sigue funcionando.

En el contexto agrario, esto es especialmente relevante porque los proveedores de software del sector renuevan sus plataformas con frecuencia: un cuaderno de campo que hoy está en un servidor Plesk puede mañana estar en la nube. Con una API REST estable y versionada, la integración con el ERP de gestión sobrevive a esos cambios.

Versionado de la API: por qué el contrato importa

Una API sin versionado rompe a los consumidores cada vez que cambia. La buena práctica es que la API publique una especificación OpenAPI (antes denominada Swagger) con un número de versión, y que los cambios que rompen compatibilidad siempre incrementen la versión mayor (v1 → v2). Los cambios aditivos —nuevos campos en la respuesta, nuevos endpoints— no rompen a los consumidores existentes que ignoran lo que no conocen.

Para el técnico integrador, esto se traduce en una regla práctica: generar el cliente de la API a partir del documento OpenAPI, no a partir de ejemplos hardcodeados. Si el proveedor del software actualizó la especificación y añadió un campo nuevo, el cliente generado lo incorpora automáticamente. Si eliminó un campo, el compilador avisa.

---

3. Tokens de API con alcance mínimo: el principio de mínimos privilegios

La autenticación contra una API REST en un contexto empresarial no debe hacerse con el usuario y la contraseña del administrador. La razón es simple: un sistema externo (el ERP, la báscula, el script de conciliación) que obtiene las credenciales del administrador puede hacer cualquier cosa en el sistema. Si esas credenciales se filtran —por un log, por un correo mal enviado o por una brecha en el ERP—, la exposición es total.

La solución es el token de API con alcance limitado (scoped API token). Cada integración recibe un token propio que solo puede hacer aquello para lo que se le ha concedido permiso explícito. El principio de diseño se llama fail-closed: si no se concede permiso para una acción, la acción no está disponible, independientemente de quién llame.

Cómo funcionan los tokens de Campodato

Campodato implementa tokens de API con el formato cdp_<32 bytes en base64url>. El prefijo cdp_ identifica el origen del secreto; el cuerpo son 32 bytes aleatorios criptográficamente seguros. Cuando el administrador de la organización crea un token desde el panel de integraciones, el sistema genera el token en claro, lo muestra una sola vez en pantalla, calcula su hash SHA-256 y almacena únicamente el hash junto con los primeros doce caracteres visibles del token (por ejemplo, cdp_a1b2c3d4…). Esos doce caracteres permiten identificar el token en la interfaz sin exponer el secreto.

Esto tiene una implicación operativa importante: si el token se pierde, no se puede recuperar. El sistema nunca almacena el secreto en claro, solo su huella criptográfica. Si el responsable de sistemas pierde el token, hay que revocar el existente y crear uno nuevo. El nuevo token tendrá un identificador diferente, y habrá que actualizar la configuración en el sistema externo que lo usaba.

Scopes: qué puede hacer cada integración

Los permisos de un token se expresan como pares <módulo>:<acción>. La acción puede ser leer (métodos GET) o escribir (métodos POST y PATCH). Una integración que solo necesita leer facturas para conciliarlas con el banco no necesita permiso de escritura en el cuaderno de campo. Si ese token se filtra, el atacante puede leer facturas pero no puede crear tratamientos fitosanitarios ni falsificar registros de cosecha.

La tabla siguiente muestra algunos scopes habituales:

El comodín *:leer puede ser apropiado para una herramienta de BI interna de la cooperativa; nunca para una integración de terceros. La recomendación es siempre el mínimo de scopes necesarios y una integración, un token: si el ERP contable y la báscula de pesaje necesitan acceso, cada uno tiene su propio token con sus propios scopes.

---

4. Webhooks firmados HMAC: el cuaderno avisa al ERP, no al revés

La API REST resuelve el caso en que el ERP quiere leer o escribir datos cuando lo decide: cada hora hace un GET a los últimos tratamientos del cuaderno, o antes de cerrar el mes lanza un POST para crear las facturas pendientes. Este modelo es válido pero tiene un problema: la frecuencia. Si el ERP hace polling cada hora, la información tarda hasta una hora en llegar. Si hace polling cada minuto, genera mucho tráfico innecesario en momentos de calma.

Los webhooks invierten esta lógica: en vez de que el ERP pregunte periódicamente, el cuaderno avisa al ERP en el instante en que ocurre un hecho. Cuando se sella una factura con la huella Verifactu encadenada, el sistema lanza automáticamente una petición HTTP al endpoint del ERP con los datos de la factura. El ERP la recibe, la contabiliza y responde con un código 200. El cuaderno registra la entrega como completada.

Firma HMAC-SHA256: cómo saber que el aviso es auténtico

Un webhook es una petición HTTP que llega desde internet. Si el ERP acepta cualquier petición en ese endpoint, un atacante podría falsificar avisos: enviar una factura falsa o un cambio de inventario que no ocurrió. La firma HMAC-SHA256 resuelve esto.

Cuando el administrador crea una suscripción webhook en Campodato, el sistema genera un secreto HMAC de 32 bytes aleatorios codificados en hexadecimal. Ese secreto se muestra en claro una sola vez —al igual que el token de API—, y se almacena cifrado con la master key del sistema. El sistema nunca lo devuelve en claro después del alta.

Cuando el sistema envía un webhook, calcula el HMAC-SHA256 del cuerpo de la petición serializado exactamente como se envía, usando ese secreto como clave. El resultado (una cadena hexadecimal de 64 caracteres) viaja en la cabecera HTTP X-Campodato-Signature.

El receptor (el ERP, el script de integración) verifica la firma así:

1. Lee el cuerpo crudo de la petición (sin parsear el JSON todavía).
2. Calcula el HMAC-SHA256 del cuerpo con el mismo secreto que configuró al crear la suscripción.
3. Compara el resultado con el valor de la cabecera X-Campodato-Signature usando una comparación en tiempo constante (para evitar ataques de oráculo de temporización que intentan adivinar la firma bit a bit).
4. Solo si la firma coincide, procesa el cuerpo.

La clave de esta verificación es que el cuerpo se firma exactamente como se envía: si el receptor reserializa el JSON (cambia el orden de las claves, elimina espacios) antes de calcular el HMAC, la firma no coincide aunque el contenido sea el mismo. Por eso el paso 1 dice "cuerpo crudo": hay que leerlo como bytes, sin pasar por un parser JSON intermedio.

Política de reintentos y registro append-only

No todos los sistemas externos están disponibles las veinticuatro horas. El receptor puede estar caído por mantenimiento, saturado de peticiones o con un timeout de red. Campodato gestiona esto con una política de reintentos exponencial con backoff: el primer intento se hace de inmediato; si falla, se reintenta tras 1 minuto; si vuelve a fallar, tras 3 minutos; luego 9 minutos, 27 minutos y 60 minutos (el tope). Tras cinco intentos fallidos, la entrega queda marcada como agotada.

Cada intento de entrega es una fila nueva en el registro de entregas. El sistema nunca reescribe ni borra filas anteriores: el registro es append-only, coherente con el principio de inalterabilidad que aplica también a los registros Verifactu y a los fichajes. Esto permite auditar qué entrega se intentó, cuándo, con qué respuesta HTTP y cuántos reintentos consumió.

El receptor puede usar la cabecera X-Campodato-Delivery (un identificador de grupo de entrega) para implementar idempotencia: si recibe la misma entrega dos veces (porque el primer intento llegó pero la respuesta 200 no llegó al emisor y se lanzó un reintento), lo detecta por ese identificador y no contabiliza el hecho dos veces.

---

5. Anti-SSRF: por qué importa en la integración agraria

Cuando un usuario configura una suscripción webhook, introduce una URL. El servidor va a hacer peticiones HTTP a esa URL cada vez que ocurra un evento. Si el servidor no valida la URL, un usuario malintencionado puede configurar una URL que apunte a la red interna de la cooperativa: http://192.168.1.1/admin, http://10.0.0.5:8080/api/restart o incluso http://169.254.169.254/latest/meta-data/ (el endpoint de metadatos de instancias en AWS que da acceso a credenciales de nube).

Este ataque se llama Server-Side Request Forgery (SSRF): el atacante usa el servidor del sistema SaaS como proxy para acceder a recursos de la red privada que no serían alcanzables directamente desde internet.

La defensa anti-SSRF consiste en que el dispatcher de webhooks valide la URL antes de lanzar la petición: bloquea rangos RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8, ::1), link-local (169.254.0.0/16, fe80::/10) y cualquier otro destino que no sea una IP pública enrutable. La validación se hace después de resolver el nombre de dominio (post-DNS), para evitar ataques de rebinding DNS en los que un nombre de dominio público resuelve a una IP privada en el momento de la petición.

Para el responsable de sistemas de la cooperativa, esto significa que no se puede configurar un webhook apuntando a un servidor interno de la red local. Si la integración con el ERP necesita recibir webhooks, el ERP debe estar accesible desde internet (con una URL pública y HTTPS), o hay que establecer un túnel o proxy adecuado.

---

6. Los tres flujos de integración más habituales

Flujo 1: volcado de facturas selladas al ERP contable

Este es el flujo más solicitado por cooperativas y explotaciones grandes que ya tienen un ERP contable (SAP, Sage, Holded, A3 ERP u otro) y no quieren cambiar el software de contabilidad, pero sí quieren que las facturas emitidas desde Campodato —con su huella Verifactu encadenada— lleguen automáticamente al ERP para contabilizarse.

Cómo funciona:

1. El agricultor o el responsable de facturación emite una factura en Campodato. El sistema calcula la huella SHA-256, encadena el registro y, si la explotación opera en modalidad Verifactu, remite el registro a la AEAT.
2. Campodato emite un evento factura.sellada con el payload que contiene el número de factura, la serie, la fecha de expedición, el importe total, el tipo de IVA aplicado, el NIF del emisor y el NIF del receptor.
3. El ERP, suscrito a ese evento, recibe el webhook, verifica la firma HMAC, parsea el payload y crea el asiento contable correspondiente.
4. El ERP responde con 200. Campodato registra la entrega como completada.

El integrador solo necesita construir el receptor del webhook en el ERP: un endpoint HTTPS que acepte POST, verifique la firma HMAC y mapee los campos del payload a las cuentas contables del plan de la cooperativa. No hay que tocar nada en Campodato salvo crear la suscripción.

Qué no se transfiere: la huella SHA-256 encadenada viaja en el payload como dato, pero la cadena de hash en sí —que garantiza la inalterabilidad de los registros Verifactu— vive exclusivamente en Campodato y en la AEAT. El ERP recibe una copia del documento, no el registro legal.

Flujo 2: partes de trabajo y costes al ERP

Cada parte de trabajo (aplicación de fitosanitario, fertilización, riego, cosecha) tiene asociados costes: horas de mano de obra, combustible de la maquinaria, litros de producto aplicado. Si esos datos fluyen automáticamente al ERP, la cuenta de explotación se construye en tiempo real.

Cómo funciona:

1. El técnico registra una operación de campo en el cuaderno (por ejemplo, un tratamiento fitosanitario en la parcela 12 con 2 litros/ha de un fungicida).
2. Campodato emite el evento operacion.creada con los datos del parte: parcela SIGPAC (recinto DGC), tipo de operación, producto, dosis, fecha, duración y técnico responsable.
3. El ERP suscrito recibe el webhook y lo mapea a un asiento de gasto: producto fitosanitario consumido del stock, horas de mano de obra imputadas a la partida de la campaña correspondiente.
4. El sistema de inventario de insumos recibe también el evento y descuenta las unidades del stock de fitosanitarios.

Este flujo cierra el ciclo de trazabilidad que exige el RD 1054/2022, con los campos del Anexo V del Documento Técnico SIEX del FEGA: el dato de la operación nace en el cuaderno con todos los campos normativos (número de registro del producto fitosanitario, dosis por unidad de superficie, parcela SIGPAC) y llega al ERP sin que nadie lo vuelva a teclear.

Flujo 3: alertas de inventario y propuestas de pedido

El cuaderno registra cada aplicación de fitosanitario o fertilizante vinculada al stock de insumos. Cuando el stock de un producto cae por debajo del mínimo configurado, Campodato emite el evento inventario.bajo_minimo.

El ERP o el sistema de compras suscrito recibe ese evento y, según la configuración, puede generar automáticamente una propuesta de pedido al proveedor habitual, enviar un aviso al responsable de almacén o bloquear la planificación de nuevas aplicaciones hasta que haya stock suficiente.

Este flujo es especialmente relevante en cooperativas con almacén colectivo de insumos: la cooperativa gestiona el stock centralizado y necesita saber cuándo reaprovisionarlo antes de que los socios lleguen a recoger producto para la siguiente aplicación.

---

7. Qué datos fluyen y qué no: los límites del RLS y el RGPD

No todos los datos de Campodato son accesibles desde la API externa. El acceso está restringido por dos capas:

Row-Level Security (RLS) a nivel de base de datos. Cada token de API está vinculado a una organización (cooperativa, asesoría o explotación individual). Las políticas RLS garantizan que las consultas realizadas con ese token solo devuelven filas que pertenecen a esa organización. No es un filtro en la capa de aplicación: es una restricción a nivel de base de datos que no se puede eludir aunque la aplicación tenga un bug. Un asesor con acceso a veinte explotaciones nunca recibe datos de la explotación número veintiuno aunque intente acceder a ella directamente por la API.

RGPD y datos personales de los trabajadores. Los registros de jornada (fichajes) contienen datos personales de los trabajadores: nombre, DNI o NIE, horas trabajadas, geolocalización del instante del fichaje (si el trabajador la activó). Esos datos tienen una base jurídica específica (el art. 34.9 del Estatuto de los Trabajadores para el registro de jornada) y un plazo de conservación de cuatro años (art. 66 de la Ley General Tributaria). No pueden compartirse libremente con cualquier sistema externo: antes de configurar una integración que incluya datos de fichaje, el responsable de datos debe asegurarse de que el sistema receptor tenga un DPA (Acuerdo de Encargado del Tratamiento, art. 28 del RGPD) firmado con Campodato.

Los registros Verifactu son append-only y no modificables desde la API. La API expone lecturas de facturas selladas, pero no permite modificar ni eliminar registros encadenados. La corrección de una factura errónea siempre genera un nuevo registro de anulación o subsanación encadenado al original, nunca una modificación del registro previo. Esto es una exigencia del RD 1007/2023 (art. 8) y del art. 29.2.j de la Ley General Tributaria: los sistemas de facturación no pueden tener software de doble uso que permita alterar o eliminar registros legales.

---

8. Tabla: casos de integración por perfil

---

9. Campodato y la integración con el ERP contable

Campodato expone una API REST documentada en OpenAPI 3.1 con autenticación por tokens de API scoped y un motor de webhooks salientes firmados HMAC-SHA256. Estos componentes son funcionales en las Olas 1-9 del producto.

Lo que Campodato ofrece hoy para la integración:

• Tokens de API con formato cdp_<base64url>, scopes por módulo y acción, caducidad configurable y revocación inmediata. El hash se almacena en SHA-256; el claro nunca se persiste.
• Webhooks salientes firmados con HMAC-SHA256 sobre el cuerpo serializado exactamente como se envía. Cabecera X-Campodato-Signature. Política de reintentos: 5 intentos, backoff exponencial de 60 segundos base, factor 3, tope 1 hora.
• Eventos disponibles hoy: operacion.creada (anotación en el cuaderno), factura.sellada (factura Verifactu encadenada), plazo.vencido (plazo normativo vencido), certificacion.por_vencer (sello de calidad en ventana de aviso), inventario.bajo_minimo (stock por debajo del mínimo).
• Registro append-only de entregas: cada intento es una fila nueva; el estado vigente es el del intento más reciente. No hay UPDATE ni DELETE en el registro de entregas.
• Defensa anti-SSRF en el dispatcher: validación post-DNS que bloquea IPs privadas, loopback y link-local.
• RLS fail-closed: los datos de cada organización están aislados a nivel de base de datos. Un token no puede acceder a datos de otra organización aunque intente hacerlo.

Y lo que antes figuraba como pendiente ya está construido, en la pantalla «Conectores e integraciones»:

• OAuth 2.1 con código de autorización y PKCE (solo S256; plain se rechaza): una app de tercero pide permiso al titular en una pantalla de consentimiento, y nadie copia ni pega tokens. La redirect_uri se coteja por coincidencia exacta contra la lista blanca del cliente registrado.
• Webhooks entrantes firmados con HMAC en POST /v2/webhooks/in/<instalación>, con verificación de firma e idempotencia, para que un sistema externo —una báscula, por ejemplo— empuje datos hacia Campodato. Cada recepción queda en un registro append-only consultable.
• Marketplace de conectores con catálogo, instalación y desinstalación por organización, ajuste de alcances, pausa y reanudación, telemetría de la instalación y credencial del tercero cifrada con el KMS.

Sobre lo que conviene no hacerse ilusiones: el catálogo de conectores es estático, es decir, no hay una tienda abierta donde cualquier desarrollador publique el suyo sin intervención.

El principio de dato único en la integración

El valor de la integración no es solo técnico: es normativo. Cuando el parte de trabajo nace en el cuaderno con todos los campos del Anexo V del Documento Técnico SIEX del FEGA (número de registro del fitosanitario, dosis, recinto SIGPAC, fecha) y ese dato fluye al ERP sin volver a teclearse, la explotación tiene una sola fuente de verdad para los datos de campo. Si la AEAT, el MAPA o el Consejo Regulador de la DOP cruzan datos de distintas fuentes, encuentran coherencia porque los datos tienen el mismo origen.

La alternativa —sistemas separados, volcados manuales, hojas de cálculo intermedias— no solo es ineficiente: es un riesgo de incumplimiento. Una discrepancia entre el cuaderno y los libros de bodega SILICIE puede derivar en un acta de inspección. Una factura que no coincide con los partes de trabajo puede generar dudas en un cruce con la declaración PAC.

Para saber cómo funciona la anotación en el cuaderno digital y qué datos exige el SIEX, consulta nuestra guía sobre el cuaderno de campo digital y el SIEX. Para entender las obligaciones de Verifactu para agricultores, ve a Verifactu para agricultores: qué cambia en 2027. Si tu interés es la trazabilidad en bodega, el artículo sobre SILICIE y los libros de bodega electrónicos cubre los requisitos de la Agencia Tributaria.

---

10. Preguntas frecuentes

¿Necesito conocimientos de programación para integrar Campodato con mi ERP?

Depende del ERP. Si el ERP tiene soporte nativo para webhooks (muchos ERP modernos como Holded o Sage 50 permiten configurar webhooks sin código), el responsable de sistemas puede configurar la integración desde la interfaz, sin programar nada. Si el ERP no tiene ese soporte, un técnico integrador necesita construir un receptor de webhooks: un endpoint HTTPS que acepte POST, verifique la firma HMAC y envíe los datos al ERP por su propia API o por una importación de fichero. Es un trabajo de integración estándar, no específico del sector agrario.

¿Un webhook puede fallar y perder datos?

Los webhooks pueden fallar si el receptor está caído o responde con un error 5xx. La política de reintentos de Campodato hace hasta cinco intentos con backoff exponencial antes de marcar la entrega como agotada. Si la entrega queda agotada, el dato no se pierde en Campodato (sigue en el cuaderno o en las facturas), pero el ERP no recibió el aviso. El responsable de sistemas debe monitorizar el estado de las entregas y, cuando haya entregas agotadas, transferir esos datos manualmente o mediante una consulta GET a la API. Una buena práctica es que el ERP haga una conciliación periódica (por ejemplo, nocturna) por API para detectar esas brechas.

¿Los datos del cuaderno de campo son accesibles desde cualquier sistema con un token?

No. Cada token de API solo puede acceder a los datos de la organización a la que pertenece, y solo a los módulos para los que se le han concedido scopes explícitos. La restricción es a nivel de base de datos (Row-Level Security), no solo en la capa de aplicación. Además, los datos de trabajadores (fichajes, jornadas) requieren un tratamiento específico bajo el RGPD y no deben compartirse con sistemas externos sin un DPA firmado.

¿Qué diferencia hay entre este artículo y el artículo técnico de la API de Campodato?

Este artículo se centra en el negocio: qué problema resuelve la integración, qué flujos son los más habituales en cooperativas y explotaciones grandes, y qué hay que tener en cuenta desde el punto de vista normativo (RGPD, Verifactu, RD 1054/2022) antes de integrar. El artículo técnico Webhooks y API de Campodato: integra el cuaderno con tu ERP o tu báscula detalla los endpoints, los formatos de los payloads, los scopes disponibles y el código de verificación de firma, y está orientado al técnico integrador que construye el conector.

¿Puedo integrar un ERP de terceros que no es el de Campodato?

Sí. La API REST de Campodato es genérica: cualquier sistema que pueda hacer peticiones HTTP puede integrarse. No se necesita que el ERP sea de un proveedor específico ni que tenga una certificación particular. Los únicos requisitos son que el receptor de webhooks tenga un endpoint HTTPS accesible desde internet (anti-SSRF impide apuntar a IPs privadas) y que implemente la verificación de firma HMAC para no aceptar webhooks falsos.

¿La integración API afecta a la cadena de hash de Verifactu?

No, en el sentido de que la API de lectura solo expone las facturas ya selladas: el hash ya está calculado y encadenado. Pero la API de escritura (si se usa para crear facturas desde un sistema externo como una báscula o un TPV) sí activa el encadenamiento Verifactu en el momento de la creación. El sistema calcula la huella SHA-256 del registro, la encadena con el registro anterior en la cadena del NIF emisor y, si la explotación opera en modalidad Verifactu, remite el registro a la AEAT. Este proceso es transparente para el sistema externo: llama al endpoint, pasa los datos de la factura y recibe la factura sellada con su huella.

---

Conclusión: la integración es una decisión de negocio antes que técnica

La pregunta que debe responder el responsable de sistemas de una cooperativa o explotación grande no es "¿puedo integrar el cuaderno con mi ERP?" sino "¿qué flujos de datos generan más trabajo manual innecesario hoy y qué riesgo normativo representan?". La respuesta a esa pregunta define qué integración tiene más valor inmediato.

En la mayoría de los casos, el volcado automático de facturas selladas al ERP contable y los eventos de cosecha desde el cuaderno son los dos primeros flujos que eliminan más horas de doble entrada y más riesgo de discrepancia. Son también los más sencillos de implementar: solo requieren configurar una suscripción webhook en Campodato y construir (o configurar) un receptor en el ERP.

Si tu cooperativa o tu explotación está evaluando cómo eliminar las islas de datos entre el cuaderno, la facturación y la contabilidad, puedes explorar cómo funciona Campodato. Para casos de integración específicos de bodega o cooperativa vitivinícola, consulta también nuestra guía sobre SILICIE y el libro de bodega electrónico y el artículo sobre factura electrónica para cooperativas agrarias y socios.

---

Fuentes

• RD 1054/2022, de 27 de diciembre, por el que se crea el SIEX (Sistema de Información de Explotaciones Agrarias) y el REA. BOE-A-2022-23054
• RD 1007/2023, de 5 de diciembre, por el que se aprueba el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación (Verifactu). BOE-A-2023-24840
• Orden HAC/1177/2024, de 17 de octubre, que desarrolla las especificaciones técnicas del RRSIF (Reglamento de Requisitos de los Sistemas Informáticos de Facturación). BOE-A-2024-22138
• RD 1039/2025, de 19 de noviembre, que modifica el art. 16 del RD 1311/2012 (registro electrónico de tratamientos fitosanitarios obligatorio desde 01-01-2027). BOE-A-2025-23421
• Reglamento (UE) 2016/679 (RGPD), arts. 6, 13, 28 y 25 (base jurídica, información, encargado del tratamiento y privacidad por diseño).
• Orden HAC/998/2019, de 23 de septiembre, por la que se regula la contabilidad de los productos objeto de los Impuestos Especiales (SILICIE), modificada por la Orden HAC/566/2020.

Nota de revisión: Las fechas de obligatoriedad del registro electrónico de tratamientos fitosanitarios (01-01-2027) y de fertilización (01-01-2026) son las vigentes a la fecha de redacción de este artículo (junio 2026). Las bases legales son RD 1039/2025 y RD 934/2025 respectivamente. Verificar con el BOE si hubo modificaciones posteriores antes de la publicación de este artículo (septiembre 2026).

---

Artículo redactado por el Equipo Campodato (Summum Marketing). Última revisión normativa: 2026-06-13.