# Introducción a Firmar vía API Fuente: /sign-via-api/sign-via-api-introduction/ Una vez que un documento fue [creado y subido](/document-management/create-document), cada firmante tiene un registro de firma (`signature.id`) que representa su pendiente de firma. Para completar o rechazar esa firma, tu integración llama a un único endpoint: **Método:** POST `https://api.digitafirma.com/v1/sign/{signatureId}` > **Nota** > > Este es el mismo endpoint sin importar qué tipo de certificado use el firmante. Lo que cambia es **qué campos envías** en el `multipart/form-data` del cuerpo. ## ¿Qué método usar? El campo `allow_type_signatures` que configuraste al [crear el documento](/document-management/create-document#allow_type_signatures-qué-certificados-se-aceptan) determina qué caminos están disponibles para ese firmante: **Certificado propio (e.firma / FIREL / TEPJF)** El firmante sube su propio certificado (`.cer` + `.key`, o `.pfx`) más su contraseña. Tu integración es responsable de recolectar esos archivos y reenviarlos tal cual al endpoint de firma. [Ver guía: Firmar con e.firma](/sign-via-api/sign-with-efirma) **Flujo guiado (VERIFICAMEX)** El firmante no trae certificado propio: valida su identidad dentro del flujo de Verificamex Firma (INE + RENAPO, o video + OTP) y el sistema le emite un certificado automáticamente. Requiere haber completado antes un flujo de firmado (`signatureFlowId`) y enviarlo junto con `signatureStroke`. ## Rechazar una firma Cualquiera de los dos métodos anteriores se reemplaza por un rechazo si envías: | Campo | Tipo | Descripción | | :- | :- | :- | | `reject` | `boolean` | Envía `true` para rechazar en lugar de firmar. | | `commentary` | `string` | Comentario opcional del motivo del rechazo (soporta texto enriquecido). | No es necesario enviar certificado, contraseña ni `signatureFlowId` cuando `reject` es `true`. > **Precaución** > > Un rechazo o una firma no se pueden deshacer ni repetir: si el `signatureId` ya está `SIGNED` o `REJECTED`, el endpoint responde con error.