Cómo elegir una API firma electrónica: siete proveedores comparados

Una API firma electrónica (también llamada API de firma electrónica, e-signature API o eSignature API) deja que tu código envíe un documento a firmar, siga su estado y recoja el archivo firmado sin que nadie abra un panel. Hemos comparado siete proveedores según lo que publican ellos mismos. Los puntos de entrada de pago más bajos que encontramos: SignWell, a 0,85 USD por documento después de 25 gratuitos al mes; el plan de API de PandaDoc, a 40 USD al mes por 40 documentos (su página no nombra ningún ciclo de facturación); y el plan para desarrolladores Starter de DocuSign, a 50 USD al mes con facturación anual.

El precio es la parte fácil. Lo que decide si una API de firma electrónica te sigue gustando al cabo de un año son cuatro preguntas: qué unidad pagas, cómo autentica, si sus webhooks van firmados y cuánto vale un envío de prueba. Esas cuatro descartan más proveedores que cualquier precio de lista.

Si vas a construir sobre Chaindoc, la API REST y los webhooks vienen con el plan Business, a 29 € al mes con facturación mensual. Cada dato de un proveedor sale abajo de su propia página, con la fecha en que la leímos.

Toda API firma electrónica hace las mismas cuatro tareas: crear una solicitud, hacerla llegar al firmante, informar de lo que pasa y entregar el archivo firmado con su evidencia. Las diferencias están en cómo se construye y se cobra cada una. Estas son las preguntas que conviene hacer antes de reservar una demo:

• Modelo de autenticación. OAuth, claves de API o ambos, y si hay una clave de solo lectura que puedas publicar en el navegador.
• Firma integrada o por correo. ¿Pueden firmar tus usuarios dentro de tu aplicación, y viene en el plan que de verdad vas a comprar?
• Webhooks: ¿van firmados los mensajes, hay ventana de repetición y puedes ver lo que se entregó?
• Plantillas. Una sola llamada que rellena una plantilla guardada y la envía te ahorra mucho código de colocación de campos.
• Un sandbox gratuito, separado de producción y honesto sobre lo que valen sus envíos.
• La unidad de precio. Sobre, solicitud de firma, documento, invitación o firma, más el ciclo de facturación.
• Exportación de evidencias: el PDF firmado, la pista de auditoría y las pruebas por API, no solo desde un panel.
• La marca en la página de firma y en los correos, y en qué plan se incluye.
• Orden de firma y límites de solicitudes, las dos restricciones que los equipos descubren al final.

La tabla pone cada pregunta junto a lo que responde la documentación de Chaindoc, para que puedas medir a todos los demás proveedores con la misma lista.

Los precios de una API firma electrónica son más públicos de lo que sugiere su fama. Seis de los siete proveedores de aquí publican un precio de entrada. Adobe vende el acceso a la API con su oferta empresarial de Acrobat Sign, y un precio público de API no consta en nuestro registro (2026-10-14). El resto sigue tres modelos:

• Planes para desarrolladores con una cuota mensual: DocuSign, Dropbox Sign y PandaDoc.
• Un paquete anual de invitaciones o una licencia por invitación: SignNow.
• Pago por documento tras una cuota mensual gratuita: SignWell.

Chaindoc no tiene una lista de precios de API aparte. Su API va dentro de la suscripción Business, así que la unidad es la misma cuota de firmas que usa la aplicación web.

Precios de la API de DocuSign, plan por plan

DocuSign cobra sus planes para desarrolladores aparte de sus planes de eSignature por usuario. En su página de precios para desarrolladores de EE. UU., leída el 14 de octubre de 2026, Starter cuesta 50 USD al mes con facturación anual (600 USD al año) o 75 USD con facturación mensual, a partir de 40 sobres al mes. Intermediate cuesta 300 USD al mes con facturación anual, a partir de 100 sobres, y Advanced 480 USD al mes con facturación anual. Enhanced se contrata con ventas, con un mínimo de cinco usuarios. No necesitas ninguno para desarrollar, porque la cuenta gratuita de desarrollador lo cubre. Para los planes por usuario, consulta los planes de eSignature de DocuSign, explicados.

La mayoría de los proveedores de API de firma electrónica usan uno de dos modelos de autenticación. Las claves de API son simples: un secreto, una cabecera, acceso completo a tu propia cuenta. OAuth 2.0 exige más configuración, pero deja que tu aplicación actúe dentro de la cuenta de un cliente con un acceso acotado y revocable. Eso importa si construyes un producto al que otras empresas conectan su propia cuenta de firma. El glosario de Dropbox Sign traza bien la línea: la clave de API para tu cuenta, un token OAuth para la de otra persona.

Sea cual sea el modelo, revisa tres cosas. ¿Hay una clave de solo lectura que puedas poner en código de frontend? ¿Puedes rotar las claves sin interrupciones? ¿Y el sandbox comparte cuenta con producción o vive aparte?

La referencia de Chaindoc documenta claves de API, no OAuth: una clave pk_ de solo lectura para el navegador y una clave sk_ de acceso completo para el servidor. Eso cubre bien la integración de una sola empresa. Para un producto multiinquilino en el que cada cliente trae su propia cuenta de firma, encaja mejor un flujo OAuth, y DocuSign, Dropbox Sign, PandaDoc y SignNow documentan uno cada uno.

La firma integrada mantiene al firmante dentro de tu producto. Tu backend abre una sesión de corta duración y la pantalla de firma carga en un iframe de tu página. La firma por correo envía en su lugar un enlace a la página alojada del proveedor. Los usuarios con sesión iniciada en tu aplicación suelen recibir la primera; las contrapartes que nunca crearán una cuenta, la segunda. La mayoría de las integraciones en producción acaban usando las dos, y está bien así.

En Chaindoc, embeddedFlow: true en la solicitud de firma activa el camino integrado. Tu servidor llama a POST /embedded/sessions, pasa el ID de sesión al Embed SDK y el firmante confirma un código de un solo uso enviado a su correo antes de firmar. Una sesión dura 10 minutos. Si dejas el indicador desactivado, el firmante recibe un enlace por correo a una página de firma alojada.

Comprueba en qué plan está la firma integrada antes de diseñar una integración en torno a ella. En la tabla de precios para desarrolladores de DocuSign en EE. UU., leída el 14 de octubre de 2026, el envío integrado está marcado en todos los planes de desarrollador, mientras que la fila de firma integrada solo lo está en los planes Enhanced, que se contratan con ventas. Pregunta a DocuSign qué plan cubre exactamente el flujo que piensas lanzar. Dropbox Sign cita la firma integrada entre las funciones de su API; en qué plan viene no consta en nuestro registro (2026-10-14).

En una integración con una API firma electrónica, un webhook que tu servidor pierde en silencio es peor que no tener ninguno. Tu sistema cree conocer el estado del contrato y se equivoca. Tres comprobaciones separan un diseño de webhooks en el que se puede confiar de otro que te despierta a las 2 de la madrugada.

Verifica la firma de cada mensaje

Comprueba la firma HMAC antes de creer nada del cuerpo, y calcúlala sobre los bytes en bruto, nunca sobre un JSON que hayas analizado y vuelto a serializar. La documentación de webhooks de Chaindoc firma {timestamp}.{rawBody} con HMAC-SHA256 y envía el resumen hexadecimal, con el prefijo v1=, en X-Chaindoc-Signature, con la marca de tiempo en X-Chaindoc-Timestamp. Si te saltas la comprobación, cualquiera que conozca la URL de tu endpoint puede enviar un evento falso de firma completada.

Rechaza repeticiones y duplicados

El mismo evento puede llegar dos veces. Guarda el identificador de entrega (Chaindoc envía un UUID en X-Chaindoc-Delivery-Id) e ignora las repeticiones. El Server SDK de Chaindoc además rechaza las entregas cuya marca de tiempo se aleje más de cinco minutos del reloj de tu servidor, y eso frena de golpe la mayoría de las repeticiones.

Confirma rápido, trabaja después

Chaindoc solo da una entrega por buena si tu endpoint responde con un 2xx en menos de 30 segundos. Reintenta varias veces una entrega fallida con espera creciente, luego se rinde, y tras fallos repetidos en muchos eventos desactiva la entrega para esa clave. Responde 200 enseguida, mete el evento en una cola y haz allí el trabajo lento. Los webhooks son una función del plan Business, se configuran por clave de API en el panel y sus registros están en Settings → API Access → Webhook logs.

Haz las mismas preguntas a cada proveedor de tu lista: qué cabecera lleva la firma, qué se firma exactamente, cuánto dura la ventana de reintentos y dónde ves lo que se envió. Si un proveedor no puede decirte si un webhook llegó, depurarás a ciegas. El flujo de eventos es además la mitad de tus pruebas, así que lee qué contiene una pista de auditoría defendible antes de decidir qué guardas.

Una API firma electrónica es solo el medio de transporte. El efecto jurídico depende de la ley que rija la operación y del nivel de firma, no de que la solicitud saliera de un panel o de una llamada POST.

La base europea es el artículo 25 del Reglamento (UE) n.º 910/2014 impide negar efecto jurídico y admisibilidad como prueba a una firma electrónica por el solo hecho de ser electrónica, y atribuye el efecto de la firma manuscrita únicamente a la firma electrónica cualificada (QES). El artículo 26 fija cuatro condiciones para la firma avanzada (AES): estar vinculada al firmante de manera única, permitir identificarlo, crearse con datos que el firmante puede mantener bajo su control exclusivo y estar vinculada a los datos firmados de modo que cualquier cambio posterior sea detectable.

En España, la Ley 6/2020 reconoce en su artículo 3.1 a los documentos electrónicos públicos, administrativos y privados el valor y la eficacia jurídica que corresponda a su naturaleza. Para la prueba de los privados, el artículo 3.2 remite al artículo 326 de la Ley de Enjuiciamiento Civil. Con un servicio de confianza no cualificado, si se impugna el documento, se aplica el apartado 3: pericial u otro medio de prueba útil, junto con el Reglamento. Con uno cualificado, el apartado 4 presume que el documento reúne la característica discutida si el prestador figuraba en la lista de confianza en ese momento, y comprobar lo contrario corresponde a quien impugna.

México tiene su propio marco: el Código de Comercio regula el comercio electrónico en los artículos 89 a 114. El artículo 89 bis impide negar efectos jurídicos a la información por estar en un mensaje de datos. El artículo 93 da por cumplida la forma escrita si la información se mantiene íntegra y accesible, y la firma si el mensaje es atribuible a las partes. El artículo 97 da por satisfecho el requisito de firma con una firma electrónica apropiada para su fin, y define la firma electrónica avanzada o fiable con cuatro requisitos: datos de creación exclusivos del firmante y bajo su control exclusivo, y alteraciones detectables tanto en la firma como en la información. Para conservar el mensaje con valor probatorio, la NOM-151-SCFI-2016 fija cómo conservar mensajes de datos y digitalizar documentos. No es lo mismo que la e.firma del SAT, que es un certificado de la autoridad fiscal.

Los proveedores ocupan peldaños distintos de esa escalera, y el plan importa. La tabla para desarrolladores de DocuSign indica el nivel simple (SES) en Starter, Intermediate y Advanced, y SES, AES y QES en Enhanced. La documentación de Chaindoc describe sus propias firmas como firmas electrónicas avanzadas PAdES con evidencia en blockchain. Chaindoc no es un prestador de servicios de confianza y no emite certificados cualificados: donde la ley exige una firma cualificada, el certificado debe venir de un prestador cualificado, algo que puede comprobarse en la lista de confianza de la UE. Nuestra guía de las firmas electrónicas cualificadas explica cómo funciona. Con una contraparte en Estados Unidos rige la ESIGN Act: impide negar efecto jurídico a una firma o a un contrato, en el comercio entre estados o con el extranjero, solo por ser electrónicos (15 U.S.C. § 7001(a)). Esto es un resumen de las normas, no asesoramiento jurídico.

Ninguna API de firma electrónica gana en todas las filas, y una comparación que lo fingiera no te serviría de nada. Por lo que hemos leído, esto es en lo que destaca cada proveedor:

• DocuSign tiene las herramientas más completas para desarrolladores: SDK en los lenguajes habituales, proyectos Quickstart descargables, colecciones de Postman y una cuenta gratuita de desarrollador que no caduca. Sus planes Enhanced listan AES y QES en la tabla de precios.
• Dropbox Sign publica SDK oficiales en seis lenguajes (Python, Ruby, PHP, Java, NodeJS y C#), y sus solicitudes en modo de prueba no cuentan contra tu cuota.
• PandaDoc ofrece un nivel de API gratuito con 60 documentos al año y un sandbox completo, sin tarjeta.
• SignNow combina un Dev Mode gratuito con invitaciones de prueba ilimitadas y 250 invitaciones gratis para probar en producción.
• Adobe Acrobat Sign tiene una Developer Edition gratuita con acceso a la API, además de un programa aparte de socios OEM e integrados para fabricantes de software.
• SignWell tiene el precio de entrada por unidad más bajo que hemos encontrado: desde 0,85 USD por documento tras 25 gratuitos al mes.
• Chaindoc mete claves de API y webhooks en un único plan fijo en euros, añade un registro de verificación en blockchain a cada versión de documento publicada y gestiona contratos con facturas por la misma API. Sus límites también son reales: dos SDK de TypeScript (sirve cualquier cliente HTTP), invitaciones enviadas todas a la vez por la API, ningún certificado cualificado propio y un límite de solicitudes por clave.

Si estás sustituyendo a DocuSign, nuestra página sobre cómo se compara Chaindoc con DocuSign va plan por plan.

Las claves de API y los webhooks de la API de Chaindoc vienen con el plan Business: 29 € al mes con facturación mensual o 278 € con facturación anual, con 100 firmas al mes y 9 € al mes por cada 10 adicionales (consulta los planes de Chaindoc). En el plan Team, el acceso a la API se concede bajo petición; Free y Personal no lo incluyen.

El buen encaje es un producto que necesita firma, prueba y pago en un solo flujo. La misma API crea documentos, envía solicitudes de firma, rellena plantillas y gestiona contratos con facturas y configuración de cobro. Cuando publicas un documento, el hash de la versión que el servidor calculó al subirlo se escribe en la cadena, y la prueba de cada firmante se registra cuando la solicitud se completa. GET /documents/versions/:versionId/verification devuelve el hash de transacción y el ID de cadena, que conviene guardar con tus propios registros. Las verificaciones de identidad son opcionales, por solicitud: activa isKycRequired: true cuando una operación lo pida; Business incluye 10 al mes.

Encaja mal un flujo que dependa de un orden de firma por API. Una solicitud hecha por API invita a todos a la vez; un orden de firma definido existe mediante las rutas de aprobación de la aplicación web en Business. Y si los flujos con agentes de IA están en tu hoja de ruta, el paquete público @chaindoc_io/mcp-server envuelve la misma API; el servidor MCP de Chaindoc para agentes de IA lo cuenta.

Dale a cada finalista los mismos cinco días.

1. 1.
   Autentícate y envía una solicitud basada en una plantilla en el sandbox.
2. 2.
   Construye el camino integrado y el camino por correo.
3. 3.
   Verifica las firmas de los webhooks, repite una entrega y apaga tu endpoint una hora para ver los reintentos.
4. 4.
   Exporta el archivo firmado y la evidencia de auditoría por la API. Es el paso que más se salta y el que muestra qué podrías presentar ante un juez.
5. 5.
   Calcula tu volumen mensual real en la unidad de cada proveedor, con el ciclo de facturación que de verdad elegirías.

La API firma electrónica que pase esa semana sin un ticket de soporte suele ser la que conviene comprar.