Skip to main content

​
Primeros pasos y cuenta

Sí. La clave principal de tu cuenta está en la página Panel del panel de control; las claves propias de cada espacio de trabajo están en la pestaña Info de ese espacio de trabajo, y no existe una página separada de “Configuración > Claves API”. También puedes obtenerlas mediante la API. Solo el Propietario del espacio de trabajo puede generar o regenerar claves desde el panel de control.Ver: Autenticación de API y tokens JWT, Guía Completa de Configuración
No, Firma.dev no ofrece un período de prueba independiente ni una cuenta sandbox, y el modo de prueba no cuesta nada usarlo. Las solicitudes con clave test siguen sujetas a los límites de frecuencia normales de la API, igual que las solicitudes live, y los editores incrustables y la página de firma alojada se comportan de forma idéntica tanto en modo de prueba como en modo live.Ver: Autenticación de API y tokens JWT, Guía Completa de Configuración
No. El registro es de autoservicio, sin contrato y sin necesidad de una demo comercial: crea una cuenta, acepta los términos de servicio estándar al registrarte, y obtén tu clave API desde el panel de control. Los precios no tienen mínimos, ni contratos, ni cuotas mensuales. Puedes integrar directamente desde la documentación, el servidor MCP, o una de las guías de integración de Firma.dev para herramientas de programación con IA (Claude Code, Cursor, ChatGPT y otras) sin necesidad de hablar nunca con ventas.
Firma.dev tiene tres roles de cuenta: Propietario, Administrador y Solo Lectura.
  • Propietario: el único rol que puede gestionar la facturación, crear, eliminar o renombrar espacios de trabajo, y generar o regenerar claves API.
  • Propietario y Administrador: ambos pueden gestionar webhooks, dominios personalizados y la configuración del espacio de trabajo o de la empresa, invitar o eliminar usuarios (aunque un Administrador no puede crear ni ascender a otro Propietario), y crear solicitudes de firma.
  • Solo Lectura: solo puede leer y copiar datos existentes.
Algunas configuraciones de interruptor a nivel de espacio de trabajo, como la verificación OTP o la visualización del marco de firma, son exclusivas del Propietario en el backend. La interfaz aún no bloquea a los usuarios Administrador o Solo Lectura para que las activen, por lo que un usuario que no es Propietario puede ver una confirmación de “guardado” aunque el cambio no se haya aplicado. Si una configuración no parece guardarse, pide a un Propietario que haga el cambio.
Por diseño, agregar un miembro del equipo crea su cuenta de inmediato en lugar de enviar una invitación por correo electrónico: la contraseña temporal del nuevo usuario se muestra una vez en pantalla en el momento de la creación, no se envía por correo. Comparte esa contraseña con la persona para que pueda iniciar sesión; luego se le pedirá que configure su propia contraseña en el primer inicio de sesión. Si la contraseña temporal se pierde antes de usarse, usa ¿Olvidaste tu contraseña? en la página de inicio de sesión para restablecerla.
Cambia tu correo de inicio de sesión desde el diálogo Mi Perfil (ábrelo desde tu avatar o “Mi Perfil” en la barra lateral); esto activa un flujo estándar de confirmación de cambio de correo hacia la nueva dirección. La pestaña Información de la Empresa de la página Cuenta también tiene un campo “Email”, pero es una dirección de contacto de facturación/notificaciones separada a nivel de empresa: cambiarla no afecta cómo inicias sesión. Registrarte con un correo diferente siempre crea una cuenta separada; Firma.dev no tiene una forma de autoservicio para fusionar cuentas. Para fusionar cuentas o eliminar tu cuenta por completo, contacta con soporte.
Los enlaces de restablecimiento de contraseña son de un solo uso y tienen tiempo limitado; una vez que un enlace se ha abierto (ya sea por ti o automáticamente en tu nombre), un segundo clic aparece como expirado o inválido, y necesitarás solicitar uno nuevo desde ¿Olvidaste tu contraseña?. Una causa común de que un enlace se consuma antes de que hagas clic en él es un escáner de seguridad de correo corporativo que abre automáticamente los enlaces del correo entrante; un buzón compartido o con alias también puede retrasar o filtrar el mensaje. Asegúrate de solicitar el restablecimiento para la dirección de correo electrónico exacta con la que está registrada tu cuenta, y contacta con soporte si el problema continúa.
Te integras a través de la API REST de Firma.dev, opcionalmente combinada con sus editores incrustables. Firma.dev también ofrece un SDK de TypeScript, y publica guías paso a paso para plataformas como n8n, Supabase y Lovable, además de los clientes de herramientas de programación con IA que cubren sus servidores MCP.Ver: Guía Completa de Configuración, Firma incrustable, Integración MCP
La API cubre todo el flujo de trabajo de firma electrónica, desde la creación de una solicitud de firma hasta la recepción de un documento firmado y sellado. Los campos también se pueden colocar con etiquetas de anclaje, con reglas de campos condicionales y obligatorios, verificación OTP por correo electrónico, y control total sobre cada correo que envía Firma.dev. Los documentos completados se sellan como PDF PAdES-B-LTA con un certificado de finalización, y cada espacio de trabajo aísla la marca, los dominios de envío y las plantillas de correo de cada cliente.Ver: Envío de una solicitud de firma, Webhooks, Registro de Auditoría

​
Precios y facturación

Un crédito cubre una única solicitud de firma, que se cobra al enviarla y nunca se reembolsa después. Un crédito equivale a una solicitud de firma (sobre), sin importar cuántos firmantes o documentos contenga. Se descuenta cuando se envía la solicitud, justo después de que salen los correos de firma y antes de que la solicitud se marque como enviada, no cuando los firmantes terminan. Los créditos no se reembolsan si un firmante rechaza firmar o la solicitud expira, y no se cobra ningún crédito si la validación de envío falla o el correo mismo no logra enviarse.Ver: Guía Completa de Configuración
Firma.dev funciona con pago por uso, sin suscripciones, mínimos ni cuotas por usuario. Los créditos no expiran. Las cuentas creadas antes del cambio de precio más reciente de Firma.dev, o registradas mediante el código de referido de otro cliente, conservan esa tarifa anterior y más baja por crédito durante toda la vida de la cuenta. Un código de referido no restringe el acceso (cualquiera puede registrarse libremente), pero otorga a ambas partes créditos de bonificación en la primera compra de la empresa referida.Ver: Guía Completa de Configuración
Descarga las facturas desde Cuenta > Créditos y Facturación, y agrega los datos de tu empresa antes de pagar. Ingresa el nombre de tu empresa, la dirección de facturación y el número de IVA en el paso Agregar número de IVA del proceso de pago de Paddle antes de pagar. Para corregir una factura ya emitida, envía un correo a support@firma.dev con el número de factura, el nombre de la empresa, la dirección de facturación y el número de IVA. Se vuelve a emitir y se muestra mediante el mismo enlace Ver.Ver: Actualizaciones de la Plataforma: descargas de facturas
Esto casi siempre lo causa un bloqueador de anuncios, una extensión de privacidad, o un filtro de red corporativo que impide que se cargue el script de pago de Paddle. Firma.dev muestra esto como “Failed to load payment system: Failed to load Paddle.js.” Intenta desactivar el bloqueador para el sitio, o abre la página en una ventana privada/de incógnito o en otro navegador. Si una compra parece haber fallado a mitad de camino, revisa Cuenta > Créditos y Facturación > Historial de Transacciones para confirmar si realmente se completó antes de volver a intentarlo, para no pagar dos veces.
Sí, la recarga automática está disponible. Compra créditos en cualquier momento desde Cuenta > Créditos y Facturación, y activa Recarga Automática en esa misma pestaña para comprar automáticamente un paquete de créditos fijo cada vez que tu saldo caiga por debajo de un umbral que tú elijas. Actualmente no hay niveles de descuento por volumen; cada paquete de créditos tiene el precio estándar por crédito de tu cuenta, sin importar cuánto compres de una vez.Ver: Guía Completa de Configuración

​
Envío de solicitudes de firma

POST /signing-requests solo crea un borrador. Nunca envía un correo electrónico por sí solo, sin importar tu settings.Ver: Envío de una solicitud de firma: Crear vs. crear y enviar
Sí, puedes suprimir los propios correos de firma y finalización de Firma.dev y enviar el enlace de firma mediante tu propio sistema en su lugar.
  • settings.send_signing_email: false: suprime el correo de notificación de Firma.dev mientras la solicitud igual se envía, y funciona tanto si llamas a /send como a create-and-send.
  • settings.send_finish_email: false: desactiva el correo de finalización de la misma forma.
  • reminders: array que proporcionas al crear que controla los correos de recordatorio, con las solicitudes basadas en documento sin recibir ninguno por defecto y las solicitudes basadas en plantilla heredando los recordatorios de la plantilla a menos que los anules.
Ver: Envío de una solicitud de firma: El indicador send_signing_email y Envío de una solicitud de firma: Incrustación de la vista de firma
La URL base correcta es:
Agrega la ruta del recurso después de ella, por ejemplo .../signing-requests. Los errores 404 suelen venir de dos fuentes:
  • https://api.firma.dev/api/v1: un segundo servidor, “Planned”, listado en la especificación pública de OpenAPI para una futura forma de la API, no un endpoint real, así que un cliente generado que apunta a él devuelve 404 en cada llamada.
  • POST /signing-requests: el endpoint real detrás de la página de referencia “Create Signing Request”, no una ruta /create-signing-request como podría sugerir el título.
Ver: Autenticación: Ejemplos de código
Un payload válido tiene una lista recipients y una lista fields; cada campo apunta a un destinatario y a una posición en la página.Cada destinatario necesita first_name, email y designation (Signer, Approver o CC). last_name y order son opcionales.Cada campo necesita:
  • type: uno de los tipos de campo admitidos, que también incluyen radio_buttons, text_area, url, file y stamp.
  • page_number: la página en la que aparece el campo.
  • position: x, y, width, height como porcentajes de la página, no píxeles.
  • recipient_id: el destinatario al que pertenece el campo.
Para hacer referencia a un destinatario que aún no has creado, dale un id temporal que empiece con temp_ (por ejemplo temp_alice) y establece recipient_id del campo con el mismo valor. La API lo asigna a un UUID real y nunca devuelve IDs temporales.No existe una propiedad metadata de nivel superior. Usa en su lugar el objeto custom_fields de cada destinatario.Ver: Envío de una solicitud de firma: Esquema del destinatario y Envío de una solicitud de firma: Tipos de campo
El tamaño máximo de documento es 50MB (52,428,800 bytes). Sube archivos grandes con el proceso en dos pasos:
  • POST /documents: sube el archivo y devuelve una upload_url prefirmada.
  • PUT: envía el archivo a esa upload_url.
  • document_id: pasa esto al crear la solicitud de firma.
Mantén el base64 en línea de document por debajo de unos 5MB, o la solicitud puede fallar con un 502. El servidor MCP no tiene herramienta de subida, así que los archivos grandes pasan por la API REST.
Sí, Firma.dev admite DOCX y lo convierte a PDF automáticamente en el servidor antes de crear la solicitud de firma.
  • POST /signing-requests: acepta un archivo DOCX cuando creas una solicitud de firma directamente.
  • POST /documents: acepta un archivo DOCX cuando subes un documento por separado.
Ese conversor solo renderiza texto, encabezados, listas y tablas. Descarta por completo cualquier imagen del DOCX, y solo carga un conjunto de fuentes de estilo latino/cirílico, así que el texto en escrituras de derecha a izquierda como el hebreo o el árabe puede salir con glifos faltantes o mal renderizado.Si tu documento tiene imágenes o una escritura no latina que necesitas preservar exactamente, expórtalo tú mismo a PDF primero (por ejemplo, LibreOffice, o Google Docs > File > Download > PDF) y envía el PDF en lugar del DOCX.
No. Los endpoints de escritura (create, create-and-send, send, resend) no tienen encabezado Idempotency-Key.Una llamada a create o create-and-send reintentada automáticamente puede crear una solicitud de firma duplicada, facturada por separado y con validez legal. Llamar de nuevo a /send sobre una solicitud ya enviada devuelve un error en lugar de duplicarla.Para evitar duplicados, guarda el id devuelto por la primera llamada y verifica su existencia, o consulta las solicitudes existentes, antes de volver a intentarlo.Ver: Integración de n8n: otras operaciones comunes
No, no puedes editar el correo de un destinatario después de enviar. En su lugar, cancela y vuelve a crear la solicitud.Puedes cancelar en silencio:
  • POST /signing-requests/{id}/cancel: el endpoint que debes llamar para cancelar una solicitud.
  • notify_signers: false: un parámetro de la propia llamada de cancelación, no una configuración en el momento de creación, que suprime la notificación al firmante.
  • send_cancellation_email: una configuración del espacio de trabajo que también debe estar habilitada para que se envíe algún correo de cancelación.
Ver: Patrones de firma: Manejo de errores: 409 ALREADY_SENT
No, una solicitud de firma tiene exactamente un documento de origen.Proporcionas exactamente uno de estos:
  • document: contenido base64 en línea.
  • document_id: el ID devuelto por una solicitud POST a /documents.
  • template_id: el ID de una plantilla existente.
Son mutuamente excluyentes, así que para combinar varios archivos en un solo flujo de firma, debes fusionarlos tú mismo en un único PDF antes de crear la solicitud.Para las plantillas específicamente, no necesitas recrear una plantilla para actualizar su archivo subyacente. Un POST a /templates/{id}/replace-document reemplaza el PDF de una plantilla conservando todas las ubicaciones de campo existentes. El reemplazo debe tener el mismo número de páginas y dimensiones de página coincidentes (dentro de 1pt) que el original, de modo que actualiza el contenido sobre el diseño existente en lugar de adjuntar un documento no relacionado.
GET /signing-requests/{id}/download devuelve el PDF firmado como una URL prefirmada.Devuelve una única download_url prefirmada de corta duración, válida hasta la marca de tiempo expires_at, para el PDF final. Para una solicitud finalizada, ese único PDF ya tiene el certificado de finalización y las páginas del registro de auditoría anexadas al documento firmado, y este endpoint no ofrece una URL de descarga separada solo para el certificado.Llamar a este endpoint se comporta de forma distinta según el estado de la solicitud de firma:
  • 409: se devuelve si lo llamas antes de que la solicitud haya sido enviada.
  • allow_partial_download: cuando está habilitado, te permite obtener una instantánea de progreso parcial mientras la firma todavía está en curso.
  • 503: se devuelve con un encabezado Retry-After mientras una instantánea de progreso parcial todavía se está generando.
Sí, puedes recuperar la imagen de la firma de un firmante y cualquier archivo que haya subido mediante la API.
  • GET /signing-requests/{id}/signers/{signer_id}/signature: devuelve la firma adoptada como un data URI data:image/png;base64,....
  • GET /signing-requests/{id}/signers/{signer_id}/initials: devuelve las iniciales adoptadas de la misma forma.
  • GET /signing-requests/{id}/signers/{signer_id}/stamps/{field_id}: devuelve una imagen de sello para el field_id dado, ya que los sellos son por campo.
  • GET /signing-requests/{id}/signers/{signer_id}/files/{field_id}: devuelve una URL de descarga prefirmada, válida durante 300 segundos, para un archivo subido a un campo de tipo file, no los bytes del archivo directamente.
  • GET /signing-requests/{id}/fields: filtra por type=file para encontrar el field_id de un archivo subido.
Los archivos subidos nunca se incrustan en el PDF firmado final ni en el certificado; solo existen como adjuntos recuperables a través de estos endpoints.
GET /signing-requests/{id}/fields devuelve todos los campos de la solicitud; lee la propiedad value de cada entrada para obtener el valor resuelto y haz coincidir por variable_name.Ver: Precarga de Campos: Lectura de los valores de los campos

​
Plantillas / campos / etiquetas de anclaje

x, y, width y height son porcentajes de la página, no píxeles. El origen es la esquina superior izquierda y y crece hacia abajo.Un campo especificado manualmente devuelve un error 400 cuando x+width>100 o y+height>100. Los campos colocados mediante etiquetas de anclaje, en cambio, se recortan automáticamente para quedar dentro de la página.
Coloca texto marcador literal en el documento y pasa un array anchor_tags en una solicitud de creación basada en documento, hasta 100 etiquetas por solicitud.Las etiquetas de anclaje aceptan todos los tipos de campo, además de dropdown_options, format_rules, multi_group_id y conditions.
remove_anchor_text hace que el texto coincidente sea invisible en el flujo de contenido del PDF, en lugar de eliminarlo.Puede fallar con fuentes incrustadas/subconjunto (CID) o cuando el texto marcador está dividido entre varios operadores de texto (text-show) del PDF. Cuando eso ocurre, el sistema dibuja automáticamente un rectángulo blanco solo sobre el área del marcador coincidente, incluso sin tener add_white_background establecido.
Este error significa que el texto del marcador de anclaje estaba dentro de un Form XObject de PDF o un grupo de transparencia que no se reproducía al leer las posiciones de los glifos.Esto ocurre típicamente en documentos HTML a PDF, donde una canalización de impresión de Chromium envuelve un elemento con opacity de CSS por debajo de 1, o un transform, dentro de un Form XObject de grupo de transparencia.El extractor reproduce el texto dentro de contextos de formulario y de grupo (excluidos los flujos de apariencia de anotaciones), así que los anclajes colocados ahí se encuentran.Si vuelve a ocurrir, es probable que el anclaje esté en una construcción de fuente/geometría malformada o inusual. Vuelve a exportar el PDF de origen con una codificación de fuente estándar.
Establece format_rules.prefilledData en un campo para autocompletarlo y bloquearlo con datos del destinatario.El firmante puede seguir editando el valor si también estableces format_rules.prefilledEditable en true.Esto funciona de la misma forma en campos colocados mediante etiquetas de anclaje, ya que las etiquetas de anclaje también aceptan format_rules.
Los campos de texto se encogen automáticamente para ajustarse al cuadro del campo cuando un valor se desborda, hasta un mínimo predeterminado de 8px.En su lugar, establece format_rules.fontSize para un tamaño inicial explícito. Si el texto sigue cortándose, agranda el campo o cambia a un textarea.
Asigna el mismo multi_group_id a un conjunto de campos para vincularlos en un grupo.
  • radio_buttons: los campos que comparten un multi_group_id forman un grupo mutuamente excluyente.
  • checkbox: los campos que comparten un multi_group_id forman un grupo independiente.
El valor almacenado de una opción de radio seleccionada es el string literal "true".Un campo checkbox se renderiza como un input de casilla de verificación nativo, no como un icono de marca de verificación personalizado.
visibility_conditions y required_conditions son objetos ConditionSet en un campo que hacen referencia al field_id de otro campo del mismo destinatario.
  • GET /templates/{id}/fields: devuelve ambas propiedades, aunque el esquema público de OpenAPI las omita.
Cuando creas una solicitud de firma a partir de una plantilla (flujo en dos pasos, create-and-send, o /duplicate), ambos conjuntos de condiciones se copian y sus referencias field_id se reasignan.
Agrega cada campo individualmente; no hay una opción masiva para colocar un campo en cada página.Para iniciales en cada página, agrega un campo initial por página en el array fields, cada uno con su propio page_number. Un único destinatario puede tener varios campos obligatorios del mismo tipo, incluidos varios campos signature.
Usa un campo date para autocompletar la fecha de firma.El campo se renderiza de solo lectura en la vista de firma y se completa con la fecha local del navegador del firmante cuando termina, no con una zona horaria del servidor.
  • date_signing_default: true: habilita el autocompletado; no existe un tipo date_signed separado.
  • timezone: la configuración del espacio de trabajo que se verifica primero para las marcas de tiempo del certificado, con UTC de forma predeterminada hasta que la configures.
  • default_timezone: el valor de respaldo a nivel de empresa que se verifica después, también con UTC de forma predeterminada hasta que la configures.
No, las plantillas no se comparten entre espacios de trabajo, ni siquiera dentro de la misma empresa.
  • POST /templates/{id}/copy: copia en profundidad los campos, destinatarios, lista de CC, recordatorios, definiciones de campos personalizados y el documento de la plantilla en otro espacio de trabajo, usando una clave API (protegida) a nivel de empresa.
  • workspace_id: el espacio de trabajo de destino que pasas en el cuerpo de la solicitud.
  • POST /templates/{id}/duplicate: en su lugar, crea una nueva solicitud de firma a partir de la plantilla, no una copia de la plantilla.

​
Experiencia de firma

Sí, puedes redirigir al firmante o personalizar la página de finalización después de firmar.
  • completion_redirect_url: redirige al firmante después de que termine de firmar.
  • completion_title: personaliza el título de la página de finalización, se establece junto con la URL de redirección.
  • completion_message: personaliza el mensaje de la página de finalización, se establece junto con la URL de redirección.
  • signing.completed: el evento que debes escuchar en su lugar, si incrustas la vista de firma.
Ver: Personalización de la página de finalización (registro de cambios de la API v1.34.0) y Firma incrustable - eventos postMessage
Puedes renombrar los botones de firma, pero no ocultarlos ni ocultar el selector de idioma.Vuelve a etiquetar el texto de los botones por idioma con signing_button_label_overrides, que cubre Finalizar, Aprobar y finalizar, Siguiente Campo Requerido, Guardar y Terminar Luego, y el diálogo de Rechazar. El botón Rechazar, el botón Guardar y Terminar Luego, y el selector de idioma siempre se renderizan y no se pueden ocultar.disable_guided_navigation desactiva el desplazamiento automático al siguiente campo, que se muestra en el panel de control como “Desactivar desplazamiento automático”.Ver: Configuración del espacio de trabajo
Sí, puedes tanto desactivarlo como personalizar su texto. La barrera de aceptación de términos se puede activar o desactivar por espacio de trabajo, o a nivel de empresa como valor predeterminado. Está activada por defecto. El texto del banner de consentimiento y su página de términos enlazada son totalmente personalizables por idioma desde Configuración de Espacio de Trabajo/Empresa > Términos, para cada uno de los 14 idiomas admitidos. Todo lo que no configures recurre primero al texto personalizado de tu empresa, y luego al banner de términos propio e integrado de Firma.dev, que ya está localizado en los 14 idiomas.Ver: Validez legal
Sí, los firmantes pueden corregir su nombre o empresa antes de firmar en enlaces reenviados.Establece identity_editable_fields en la solicitud de firma o la plantilla, por ejemplo name y company, para que el firmante pueda editar sus propios datos antes de firmar. Aparece un diálogo de corrección justo después de que acepten los términos, y cada edición se registra en el registro de auditoría.Ver: Patrones de firma - Patrón: segundo firmante dinámico
Los firmantes pueden dibujar o escribir su firma, puedes exigir firmas dibujadas a mano, y el cirílico es compatible.Al escribir, se detecta automáticamente la escritura del firmante (latina, cirílica, griega, japonesa, coreana) según su nombre y se ofrecen estilos de fuente a juego; no existe una opción separada para subir una imagen. Establece hand_drawn_only en true en la solicitud de firma o la plantilla para eliminar la pestaña Escribir y exigir el dibujo.Firma.dev no admite certificados X.509 proporcionados por el firmante; aplica su propio sello PAdES al documento completado del lado del servidor.Ver: Patrones de firma
Pide al firmante que haga una actualización forzada de la página. Si eso no ayuda, abre el enlace en una versión reciente de Chrome, Firefox o Safari con los bloqueadores de contenido y de anuncios desactivados, ya que los bloqueadores pueden interferir con los scripts de la página de firma. En Safari de iOS, asegúrate de que iOS y Safari estén actualizados y vuelve a intentarlo; las versiones más antiguas podían quedarse sin memoria con PDF muy grandes o de alta resolución.
Sí, agrega ?zoom= a la URL de firma.Ver: Firma incrustable: parámetros de la URL
El mensaje de error de un enlace de firma depende del estado de la solicitud de firma: aún no enviada, expirada, ya completada por ese destinatario, o rota, mal escrita, o cancelada.
  • Not sent yet: abrir el enlace antes de que el remitente realmente envíe la solicitud muestra este mensaje.
  • Expired: ha pasado la ventana expiration_hours de la solicitud, medida desde el momento en que se envió; como una solicitud enviada no se puede editar, el remitente necesita crear una nueva en lugar de extenderla.
  • Already signed: ese destinatario específico ha completado su firma; está vinculado a su propio enlace único, así que no ocurrirá si un firmante distinto abre su propio enlace.
  • Invalid: un enlace roto o mal escrito, o uno de una solicitud cancelada, produce su propio error distinto en lugar de “ya firmado.”
No a ambas. No existe un modo integrado de “cualquiera de los firmantes”; tu aplicación debe decidir quién firma específicamente antes de crear la solicitud. Tampoco existe firma desatendida o automática en nombre de tu propia empresa; todo firmante, incluida una persona de tu equipo, debe abrir su enlace y completar el flujo de firma.Ver: Patrones de firma - Patrón: firma en paralelo
Nada se rompe. El enlace de firma de cada destinatario se identifica por su propio ID de destinatario, no por correo electrónico, así que dos firmantes pueden compartir la misma dirección de correo sin conflicto, y reenviar un enlace no permite que otra persona se convierta en un firmante distinto. Si un enlace llega a la persona equivocada, identity_editable_fields permite que el firmante real corrija su propia identidad antes de firmar, y esa corrección queda registrada en el registro de auditoría.Ver: Patrones de firma - Patrón: segundo firmante dinámico
Activa QR Code on Signing Page en la configuración del espacio de trabajo para habilitar la firma con código QR en un teléfono.Esto establece show_qr_code en true. Agrega el marcador {{signing_qr_code}} a tus plantillas de correo electrónico para que aparezca el código QR.Ver: Configuración del espacio de trabajo - Código QR en correos

​
Verificación de identidad (OTP)

Un código OTP es válido durante 10 minutos, con hasta 3 intentos antes de que necesites solicitar uno nuevo.El reenvío tiene un límite de una vez cada 60 segundos, y estos valores son fijos: no son configurables por espacio de trabajo ni por solicitud.Una vez que verificas un código, Firma.dev almacena un token de sesión en tu navegador y emite una nueva sesión de firma de 4 horas en cada visita posterior, así que reabrir el mismo enlace de firma en el mismo navegador dentro de esa ventana omite el aviso de OTP. Esa sesión renovable tiene un tope de 12 horas desde tu última verificación exitosa, después de las cuales se te pedirá verificar de nuevo sin importar la actividad.
Puedes definir el idioma del correo OTP por solicitud, pero no su redacción. Establece language en la propia solicitud de firma para anular los valores predeterminados del espacio de trabajo y de la empresa en los correos dirigidos al firmante de esa solicitud, incluido el correo OTP. Las plantillas de correo personalizadas no pueden cambiar la redacción del correo OTP, pero puedes omitir el OTP por completo en una solicitud estableciendo settings.require_otp_verification en false.Ver: Localización, Marca blanca
No. Firma.dev actualmente solo admite OTP basado en correo electrónico para la verificación de identidad del firmante; no existe integración con OTP por SMS ni con eID nacional (BankID, MitID, FranceConnect o similares). El OTP por correo electrónico está incluido sin costo adicional en el precio plano por sobre de Firma.dev. Esto no se indica en ninguna parte como un elemento de la hoja de ruta a corto plazo, así que trátalo como algo no compatible actualmente y no como algo planeado.

​
Webhooks

Esto usualmente significa que el interruptor de webhooks a nivel de cuenta está apagado, aunque el espacio de trabajo se muestre habilitado con cero fallos.Actívalo en Settings > Webhooks, o mediante la API:
  • PATCH /workspaces/{id}: establece webhook_enabled en true en el cuerpo para habilitar los webhooks sin usar el panel.
  • ignore_company_webhooks: asegúrate de que esto no sea true en el espacio de trabajo; excluye silenciosamente al espacio de trabajo de los webhooks de la empresa.
El botón de prueba del panel omite el interruptor maestro, por lo que las pruebas tienen éxito mientras los eventos reales se omiten con cero fallos.Ver: Webhooks
Los webhooks a nivel de empresa y a nivel de espacio de trabajo se diferencian en sus secrets de firma, su comportamiento de exclusión, y en cómo se dispara el evento de visualización.
  • Secrets: los webhooks a nivel de empresa y a nivel de espacio de trabajo tienen cada uno su propio secret de firma.
  • ignore_company_webhooks: permite que un espacio de trabajo se excluya por completo de los webhooks de su empresa, sin afectar a otros espacios de trabajo.
  • signing_request.viewed: se dispara solo en la primera visualización de un destinatario, no en cada apertura posterior.
Ver: Webhooks, Webhooks, Webhooks
Firma.dev no sigue redirecciones HTTP al entregar webhooks; esto es una protección deliberada contra SSRF, así que un endpoint que redirige falla la entrega directamente. Registra la URL exacta que expone tu servidor; una discrepancia en el esquema, un subdominio www, la ruta, o una barra final faltante o de más hace fallar cada intento de entrega.Ver: Webhooks
Tu endpoint debe responder con un 2xx dentro de 5 segundos; las entregas fallidas se reintentan automáticamente, y el endpoint se desactiva después de 50 fallos consecutivos. Puedes reintentar un solo evento desde el registro de eventos del panel, pero no hay reenvío masivo, y los eventos anteriores a la existencia del webhook nunca se completan retroactivamente.Ver: Webhooks
No, usa webhooks en lugar de consultar periódicamente el estado.
  • GET /signing-requests/{id}: no consultes este endpoint periódicamente para el estado; los webhooks envían las actualizaciones en su lugar.
Ver: Límites de Tasa, Webhooks

​
Entrega de correo y plantillas

RECIPIENT_EMAIL_SUPPRESSED (HTTP 422) significa que el destinatario está en la lista de supresión de Firma.dev; contacta a soporte para desbloquear una dirección.Ver: Entregabilidad de Correo, Solicitar la eliminación
El nombre del remitente proviene del nombre del espacio de trabajo y, si no existe, del nombre de la empresa. La dirección usa tu dominio de envío verificado; define su parte local con email_local_part a nivel de empresa o de espacio de trabajo.Ver: Dirección de remitente personalizada
Controla esto mediante el objeto settings de la solicitud de firma:
  • send_finish_email: false: detiene el correo de finalización.
  • attach_pdf_on_finish: false: envía un enlace de descarga en lugar de adjuntar el PDF.
  • document_only_download_url: comparte el documento sin el certificado, en lugar de final_document_download_url.
  • certificate_only_download_url: devuelve solo el certificado.
  • allow_download: false: desactiva por completo los enlaces de descarga, como control independiente de attach_pdf_on_finish.
Los destinatarios en copia reciben el documento completado como adjunto de correo con los mismos ajustes que la copia del firmante.Ver: Desactivar los correos de Firma.dev
Las plantillas personalizadas usan la sintaxis {{placeholder}}.La sintaxis heredada [bracket] también funciona y no distingue mayúsculas y minúsculas; un marcador no resuelto se renderiza como nada, no como texto sin procesar.
  • {{team_name}}: un alias de {{workspace_name}}.
  • {{team_email}}: un alias de {{workspace_email}}.
  • {{download_link}}: se resuelve solo en los correos de finalización.
No, las plantillas no varían por idioma: una plantilla se aplica a todos los destinatarios, así que las plantillas de marca por idioma necesitan un espacio de trabajo separado cada una. No hay vista previa en vivo ni variables personalizadas por solicitud.Ver: Plantillas de correo personalizadas
Sí, mediante la API; el ajuste aún no está expuesto en el panel.
  • timezone: una zona horaria IANA que se establece en el espacio de trabajo mediante la API de configuración.
  • default_timezone: el valor de respaldo a nivel de empresa cuando no se ha establecido la zona horaria del espacio de trabajo.
Marcadores como {{expiration_date}} en los correos de firma usan esa zona horaria y el idioma del correo. UTC sigue siendo el valor predeterminado cuando no se establece ninguno de los dos.Ver: Zonas horarias admitidas
El idioma se resuelve primero por solicitud de firma, luego por espacio de trabajo y después por empresa.Una empresa o un espacio de trabajo creados a través de la API usan en de forma predeterminada, salvo que definas language de forma explícita. Defínelo en el espacio de trabajo, o pasa language en la solicitud, y los nuevos correos al firmante lo usarán.Ver: Configuración del idioma de los correos

​
Dominios de envío personalizados

Configurar un dominio de envío personalizado requiere unos cuantos registros DNS agregados en dos etapas: uno para verificar la propiedad, y luego unos cuantos más para finalizar. No se necesita ningún registro MX en ningún paso, ya que Firma.dev solo envía correo a través del dominio y nunca lo recibe.Ver: Registros DNS que necesitarás
Un estado ‘Domain Conflict’ (o un ‘Configuring’ atascado) significa que el dominio ya está registrado bajo una cuenta de Resend distinta, con frecuencia la tuya propia; la solución es un subdominio dedicado como sign.tuempresa.com, que se verifica de forma independiente. Eliminar el dominio de Firma.dev libera el registro propio de Firma.dev para reutilizarlo en otro lugar, pero no tiene efecto sobre un registro en la cuenta de Resend de otra persona.Ver: ¿Ya usas Resend para tu propio correo?
Llama a verify-dns de nuevo; verifica en tiempo real cada vez, así que un contratiempo transitorio puede reportar el dominio como sin verificar incluso cuando el DNS es correcto.Ver: Estados de verificación, Peculiaridad de visualización conocida
Un dominio verificado pasa a ‘Failed’ cuando sus registros DNS dejan de validarse. Firma.dev solo lo marca como inválido después de dos verificaciones en segundo plano fallidas consecutivas, no en el primer contratiempo, para evitar fluctuaciones por un problema transitorio. Mientras un dominio esté fallido o aún sin verificar, Firma.dev envía automáticamente desde su propio dominio predeterminado en lugar del tuyo.Ver: Un dominio verificado luego muestra Failed
Sí, agrega y verifica el dominio por separado en cada espacio de trabajo donde quieras usarlo.Ver: Dominios Personalizados, Dominios de correo personalizados
Firma.dev proporciona una Firma Electrónica Avanzada (AES) bajo eIDAS Art. 3(11)/26, que cumple con el mínimo de admisibilidad de eIDAS y con los requisitos de la ESIGN Act/UETA para la mayoría de los contratos; Firma.dev no es un Proveedor de Servicios de Confianza Cualificado y no emite Firmas Electrónicas Cualificadas. El sello en sí es PAdES-B-LTA (Baseline Long-Term Archival), emitido desde la propia autoridad certificadora de Firma.dev, con una marca de tiempo RFC 3161 incrustada.Ver: Validez Legal y Cumplimiento eIDAS
El sello digital de Firma.dev es emitido por la propia autoridad certificadora de Firma.dev, que no encadena con la Lista de Confianza Aprobada de Adobe (AATL) ni con la Lista de Confianza de la UE (EUTL), así que Acrobat y visores similares no mostrarán la marca de verificación verde automática; el sello en sí sigue siendo completamente válido. Verifícalo en el panel de firmas de tu visor de PDF, o de forma independiente en app.firma.dev/validate-signature.Ver: Por qué no hay marca de verificación verde en Adobe Acrobat
Tus datos permanecen enteramente dentro de la UE, y Firma.dev no está certificada SOC 2 ni ISO 27001, aunque sus prácticas se alinean con ambos marcos.Ver: Seguridad y Cumplimiento
Puedes eliminar una solicitud de firma sin enviar (borrador) en cualquier momento, desde el panel o mediante la API:
Una vez que una solicitud ha sido enviada, ya no puede eliminarse, solo cancelarse. Un documento completado y firmado es un registro legal: los datos capturados por un firmante nunca se modifican después de firmar, y no existe un endpoint de autoservicio para eliminar los datos de un solo firmante de él. Si necesitas que se elimine una solicitud de firma completada para satisfacer una solicitud de protección de datos, contacta a support@firma.dev.
El certificado de finalización se genera en el idioma configurado de tu espacio de trabajo, no en el idioma del firmante individual ni con una anulación a nivel de solicitud de firma, y sí, puede mostrar tu logotipo. Usa una cadena de respaldo: logotipo del espacio de trabajo, luego logotipo de la empresa, luego el logotipo predeterminado de Firma.dev, e imprime el nombre propio del espacio de trabajo. Las marcas de tiempo del certificado usan la zona horaria configurada del espacio de trabajo, con UTC como respaldo si no se ha establecido ninguna.
No. Firma.dev aplica su sello PAdES-B-LTA una sola vez, en el momento de la firma, y nunca lo vuelve a sellar ni lo renueva después; para ventanas de retención muy largas, aplica tu propio re-sellado de tiempo al archivar el archivo. Si se impugna una firma, las responsabilidades de identidad del firmante, consentimiento y conservación de registros se establecen en los Términos de Servicio de Firma.dev.Ver: Validez Legal: Qué proporciona Firma.dev, Registro de Auditoría
No, no puedes eliminar el encabezado de ID de solicitud de firma del PDF firmado.Signing Request ID: <id> se dibuja en cada página del PDF firmado y del certificado de finalización, en texto gris pequeño cerca del margen superior; no hay ningún ajuste de espacio de trabajo o de API para desactivarlo.El encabezado se dibuja con una fuente incrustada, por lo que los documentos sellados pasan la validación PDF/A-2b.
Firma.dev es adecuado para la mayoría de los casos de uso en Francia bajo eIDAS y el RGPD, pero no para datos de salud regulados por HDS: Firma.dev no cuenta con la certificación HDS (alojamiento de datos de salud en Francia). Las firmas se sellan como PAdES-B-LTA. En el marco del RGPD, Firma.dev actúa como encargado del tratamiento; hay un Acuerdo de Tratamiento de Datos disponible bajo petición en support@firma.dev.Ver: Seguridad, Validez legal y cumplimiento eIDAS

​
Espacios de trabajo y multiinquilino

Sí, dar a cada cliente final su propio espacio de trabajo es la recomendación predeterminada de Firma.dev para plataformas multiinquilino; los datos de un espacio de trabajo nunca son visibles desde otro. No hay límite en cuántos espacios de trabajo puedes crear bajo una empresa, ni costo adicional por espacio de trabajo.Ver: Arquitectura Multiinquilino, Espacios de Trabajo
Cada empresa recibe exactamente un espacio de trabajo predeterminado, creado automáticamente al registrarse y marcado como protected.Está pensado para gestionarse desde el panel en lugar de la API; llamar a un endpoint de gestión sobre él con una clave API normal devuelve un 403 con el código PROTECTED_WORKSPACE.Para ajustes a nivel de cuenta, usa:
Este endpoint acepta default_timezone y language, entre otros campos. Para todo lo que necesites gestionar directamente mediante la API, crea espacios de trabajo separados y no protegidos en su lugar.Ver: Espacios de Trabajo: Casos límite y solución de problemas, Configuración del Espacio de Trabajo: Actualizar la configuración del espacio de trabajo

​
Marca blanca e incrustación

Puedes poner en marca blanca los correos de solicitud de firma, el texto de aceptación de términos del firmante, y la página de firma e incrustaciones, pero api.firma.dev en sí no puede colocarse tras un proxy bajo tu propio dominio, solo el dominio de envío de correo es personalizable. El certificado de finalización también puede ponerse en marca blanca, con tu logotipo reemplazando al de Firma.dev. show_custom_branding_only solo elimina la línea de contacto de soporte de Firma.dev de los correos; no elimina la presencia de Firma.dev de la propia página de firma.
Establece los colores y un logotipo del espacio de trabajo con estos dos endpoints:
Estos ajustes se aplican en la página de firma, las incrustaciones y los correos de firma.Ver: Marca Blanca
Establece initialZoom para controlar directamente el zoom inicial del editor de plantillas incrustado.autoFit (booleano) es la alternativa; initialZoom (número) tiene prioridad cuando se establecen ambos. Cada lienzo de documento admite el desplazamiento arrastrando con el botón central del ratón, dejando el clic izquierdo libre para la interacción con campos.Las URL de documentos firmados expiran después de 1 hora. El editor de plantillas incrustado ahora solicita automáticamente una URL nueva y reintenta hasta 3 veces en lugar de fallar.Si las descargas están bloqueadas, revisa si hay un atributo sandbox en tu propia página; los ejemplos de incrustación de Firma.dev no establecen ninguno.Ver: Editor de plantillas incrustable
Ninguna de las dos opciones es compatible actualmente. Las incrustaciones de Firma.dev (el editor de plantillas, el editor de solicitudes de firma, y la página de firma) no aceptan CSS personalizado, y no hay opción para renderizar solo un campo de firma en lugar del documento completo. Si esto está bloqueando tu integración, comparte el caso de uso con el soporte de Firma.dev.

​
Herramientas / SDKs / límites

Firma.dev proporciona dos servidores MCP, el Data MCP para acceso a la cuenta y el Docs MCP para consulta de documentación; la mayoría de los desarrolladores conectan ambos.Ver: Integración MCP
Firma.dev ofrece un SDK oficial, el cliente TypeScript @firma-dev/sdk, generado a partir de la misma especificación OpenAPI que la referencia de la API:
No hay un SDK oficial de Python ni un compromiso publicado en la hoja de ruta para uno; llama directamente a la API REST, por ejemplo con la librería requests.Ver: SDK de TypeScript para la API de Firma.dev
Los límites de tasa se aplican por clave de API y varían según la operación que estés llamando.Ver: Límites de Tasa
Este error del lado del cliente significa que la solicitud de tu navegador a una función edge nunca llegó al servidor:
Proviene del SDK de JS de Supabase, por ejemplo debido a un bloqueador de anuncios, un filtro DNS, una conexión sin conexión, o un bloqueo CORS; es una clase de error distinta a una respuesta de error genuina de la propia función.En la página de firma de Firma.dev, esto proviene más comúnmente de una llamada de analítica en segundo plano, que falla silenciosamente y no afecta tu capacidad de ver o firmar el documento.Si está ocurriendo en una llamada que realmente está bloqueando tu integración en lugar de en la analítica, revisa las condiciones de tu red antes de tratarlo como un error del lado de Firma.dev.

​
Para firmantes (recibiste un documento)

Por defecto, todos los involucrados en la solicitud de firma, incluidos los destinatarios en copia (CC), reciben por correo una copia del documento completado una vez que todos los firmantes han terminado, no inmediatamente después de que tú firmes personalmente. El correo adjunta el PDF automáticamente cuando pesa menos de 8MB; los archivos más grandes llegan como un enlace de descarga en su lugar. No hay inicio de sesión ni panel para firmantes donde recuperar documentos pasados por tu cuenta, así que si necesitas una copia antes de que todos los demás hayan terminado, pídesela a la persona que te lo envió (indicada en tu correo de invitación).
Contacta al remitente indicado en tu correo de invitación. Firma.dev es la plataforma de firma electrónica que ellos usaron para enviar el documento, no una parte del acuerdo, así que Firma.dev no puede responder preguntas sobre sus términos, reenviar un enlace expirado, ni actuar en nombre del remitente. Si aún no has terminado de firmar, puedes rechazar la solicitud en su lugar; una vez que has firmado, esa firma es parte del registro legal permanente y no puede deshacerse por nadie, incluido el soporte de Firma.dev. Firmar siempre es gratuito para ti: solo se factura la cuenta del remitente.