Package Information
Released: 1 mo ago
Downloads: 81 weekly / 867 monthly
Latest Version: 2.0.0
Author: g-digital by Garrigues
Documentation
EAD Enterprise Suite — n8n connector
MCP server for EAD Enterprise Suite - signatures, evidence, notifications, dossiers via AI agents.
Install this connector and use EAD Enterprise Suite operations as steps inside any n8n workflow. Each operation maps to one capability of the underlying EAD Enterprise Suite platform.
Install (self-hosted n8n)
npm install @g-digital/n8n-nodes-ead-enterprise-suite
Then restart n8n. The node will appear in the Nodes panel under "EAD Enterprise Suite".
Using with n8n AI Agent
For AI-driven automation, configure an n8n AI Agent node with the following system prompt. It covers all lifecycle workflows: evidence creation, certified notifications, signature processes, dossier certification.
→ Full system prompt and workflow guide: @g-digital/n8n-agent-system-prompt — see the docs/n8n-agent-workflows/gocertius-ead-system-prompt.md in MCP_Market_Distribution.
Quick system prompt snippet
Paste this into your AI Agent node's System Message:
You are a Digital Trust assistant using the EAD Enterprise Suite n8n connector.
UUID generation: generate UUID v4 for all `id` fields you must supply.
IDs from responses: never invent path parameters — always use values returned by previous tool calls.
Async operations: after evidence_seal, dossier_certify, signature activation — poll the corresponding list/status tool until the terminal state is reached before proceeding.
File uploads: when a tool returns uploadFileUrl or url, PUT the file bytes there with a separate HTTP Request node before calling the next step.
See the full lifecycle guide at: https://github.com/g-digital-by-Garrigues/MCP_Market_Distribution/blob/main/docs/n8n-agent-workflows/gocertius-ead-system-prompt.md
Operations
| Operation | Description |
|---|---|
evidence_create |
Registers a NEW evidence record inside an evidence group. Requires: evidence_group_create → evidenceGroupId, case_file_create → caseFileId. Generate a UUID v4 for ID. Compute the SHA-256 hex hash of the file BEFORE calling. Normal INTERNAL flow: call evidence_create with custodyType INTERNAL and NO fileUrl; the API returns uploadFileUrl, a presigned S3 URL. You MUST PUT the exact file bytes to uploadFileUrl, then verify with evidence_get/evidence_list, and ONLY THEN call evidence_seal. Do not seal an evidence group until every INTERNAL evidence file has been uploaded. Convenience flow: if you pass fileUrl (public HTTPS, no redirects, under 1 GiB), this tool downloads that URL and PUTs the bytes to uploadFileUrl for you. EXTERNAL flow: use custodyType EXTERNAL only when you intentionally register hash-only evidence; still generate a fresh UUID for each evidence. If an INTERNAL evidence creation/upload failed and you want to retry as EXTERNAL, create a NEW evidence ID; do not reuse an ID whose outcome is unknown. WARNING: the API sometimes returns {code:'EvidenceCreateError'} even when the evidence was successfully persisted — always verify with evidence_list before retrying. |
evidence_list |
Lists all evidence records in a specific evidence group. Requires: caseFileId and evidenceGroupId. Returns paginated list with IDs, titles, status, and timestamps. |
evidence_seal |
Seal and certify an evidence group. Closes the group to new additions and triggers async timestamping. Returns immediately — the group transitions OPEN → CLOSING → CLOSED. Poll evidence_group_list until status is CLOSED before linking to a dossier. |
evidence_get |
Retrieves a specific evidence record. Requires: evidence_create → evidenceId, evidence_group_create → evidenceGroupId, case_file_create → caseFileId. Returns status (COMPLETED|IN_PROCESS|ERROR), hash, and tspTimestamp when certified. |
evidence_group_create |
Creates an evidence group inside a case file. Requires: case_file_create → caseFileId. Generate a UUID v4 for ID. Set evidenceType to FILE, PHOTO, VIDEO, or WEB_PLUGIN. Returns evidenceGroupId. One group can contain multiple evidence records. |
evidence_group_list |
Lists all evidence groups in a case file with their current status (OPEN, CLOSING, CLOSED). Use to find an existing group or check which groups are ready for sealing. Requires: caseFileId. |
dossier_create |
Creates a dossier to aggregate certified evidence groups into a single tamper-evident PDF. Requires: case_file_create → caseFileId. Evidence groups must be in CLOSED status before linking. Generate a UUID v4 string for ID. Returns dossierId. After creation, link evidence with dossier_evidence_link, then certify with dossier_certify. |
dossier_update |
Updates the metadata of an existing dossier. Requires: dossier_create → dossierId, caseFileId. Only available while dossier is in DRAFT status. |
dossier_certify |
Certifies a dossier, generating a tamper-evident PDF and locking all linked evidence. Requires: dossier_create → dossierId, dossier_evidence_link (evidence linked), case_file_create → caseFileId. ASYNC: transitions DRAFT → CERTIFYING → CERTIFIED. Poll dossier_list until dossierId status === CERTIFIED. |
dossier_list |
Lists all dossiers in a case file. Requires: caseFileId. Returns paginated list with IDs, names, status, and creation dates. Use to monitor certification progress — poll until status: CERTIFIED. |
dossier_list_by_user |
Lists every dossier belonging to a user, across all of their case files. Requires: userId (from session_login or session_info). Use this when you do not know which case file a dossier is in; use dossier_list when you already have a caseFileId. Supports filter, order and page. Returns { data, meta.totalElements }. |
dossier_get |
Retrieves full details of a specific dossier including status, linked evidence, and download URLs. Requires: caseFileId and dossierId. |
dossier_template_list |
Lists available dossier templates. No prerequisites. Returns template IDs and their translations per language. Use the returned ID as dossierTemplateId in dossier_create. |
dossier_preview |
Returns an HTML preview URL of a dossier before certification. Requires: caseFileId and dossierId. |
dossier_document_url |
Returns the download URL for the certified dossier PDF. Requires: dossier_certify (CERTIFIED status), caseFileId, dossierId. |
dossier_package_url |
Returns the download URL for the full dossier package (PDF + evidence files). Requires: dossier_certify (CERTIFIED status), caseFileId, dossierId. |
dossier_visibility |
Updates the visibility (public/private) of a certified dossier. Requires: dossier_certify (CERTIFIED status), caseFileId, dossierId. |
dossier_delete |
Deletes a dossier. Available in DRAFT status (to discard before certification) or in CERTIFIED status (to permanently remove the certified dossier). Irreversible. Requires: caseFileId and dossierId. |
dossier_group_certify |
Creates AND certifies a dossier from a single sealed evidence group in one call (express path). Requires: evidence_seal (CLOSED), case_file_create → caseFileId, evidence_group_create → evidenceGroupId. Generate a UUID v4 string for ID. Returns dossierId with CERTIFYING status → poll until CERTIFIED. |
dossier_evidence_link |
Links evidence items from a sealed group to a dossier. Requires: dossier_create → dossierId, evidence_seal (CLOSED), case_file_create → caseFileId. Pass the ids array of evidence UUIDs. Can be called multiple times for evidence from different case files. |
dossier_evidence_list_to_link |
Lists evidence items available to be linked to a dossier (CLOSED groups not yet linked). Requires: caseFileId and dossierId. |
dossier_evidence_list |
Lists the evidence items linked to ONE evidence group of a dossier. Requires: caseFileId, dossierId AND dossierEvidenceGroupId — all three are mandatory. For every evidence item in the dossier regardless of group, use dossier_evidence_list_by_dossier instead. Supports filter, order and page. |
dossier_evidence_list_by_dossier |
Lists every evidence item linked to a dossier, across all of its evidence groups. Requires: caseFileId and dossierId. This is the dossier-wide view; dossier_evidence_list is the narrower per-group one and additionally needs a dossierEvidenceGroupId. Supports filter, order and page. Returns { data, meta.totalElements }. |
dossier_evidence_get |
Retrieves details of a specific evidence item linked to a dossier. Requires: caseFileId, dossierId, evidenceId. |
dossier_evidence_delete |
Removes an evidence item from a dossier. Only available while dossier is in DRAFT status. Requires: caseFileId, dossierId, evidenceId. |
notification_document_add |
Attaches a document to a notification. Two steps: this call registers the file and returns { url }, a presigned upload URL, and you then PUT the raw bytes to that URL with an x-amz-checksum-sha256 header. Generate a UUID v4 for ID, and compute the file's SHA-256 hex hash BEFORE calling — it goes in hash. ORDER MATTERS AND GETTING IT WRONG FAILS THE SEND: add every document BEFORE adding recipients, and wait until each document reaches READY_TO_SEND (poll notification_document_list; roughly 8 seconds) before calling notification_request_send. Attaching after recipients, or sending while a document is still PENDING, returns 409/404 NOTIFICATION_NOT_FOUND. The maximum number of attachments is a per-subscription setting rather than a fixed API limit, so do not assume a number. Attachments can be bundled into the delivery certificate — see notification_certificate_package_url. |
notification_request_create |
Creates a certified notification request. Requires: case_file_create → caseFileId. Generate a UUID v4 for ID. Set language to en_GB or es_ES. Returns notificationRequestId. Add at least one receiver with notification_receiver_add before sending. IMPORTANT: The content field must be valid HTML — plain text without HTML tags will not render on the recipient landing page. Only the following HTML formats are supported: paragraphs (), bold (), italic (), unordered lists ( |
notification_request_send |
Trigger delivery of a certified notification to all added recipients. Returns immediately — delivery is async. Poll notification_request_status until status is DELIVERED before retrieving certificates. |
notification_request_status |
Checks the delivery status of a certified notification. Requires: notificationRequestId, caseFileId. Returns status (CREATING|DRAFT|IN_PROCESS|SENT|PARTIALLY_READ|FULLY_READ|PARTIALLY_ANSWERED|FULLY_ANSWERED). Poll until status is SENT or beyond. Do not call notification_certificate_get while status is CREATING, DRAFT, or IN_PROCESS. |
notification_receiver_add |
Adds a recipient to a notification request. Requires: notification_request_create → notificationRequestId, case_file_create → caseFileId. The ID can be a UUID v4 or custom string. Returns receiverId — save it for notification_certificate_get. Delivery is by email always; set sendWaUrl for a WhatsApp link, sendSmsUrl for an RCS/SMS link (the channel negotiates: RCS where the handset supports it, SMS otherwise), and otpRequired to challenge the recipient with a one-time code. Any of those three needs phonePrefix (with the +) and phoneNumber. Add all receivers before calling notification_request_send — but if the notification has attachments, add those FIRST (see notification_document_add). |
notification_certificate_get |
Creates or retrieves a PDF certificate for a specific notification receiver. Requires notification_request_send and notification_receiver_add. Generate a UUID v4 for ID the first time and reuse that ID when polling. This tool is idempotent: it first lists existing certificates for the receiver and, if ID already exists, returns it instead of creating it again. If the certificate status is CERTIFIED, the response includes documentUrl when available. If it is CERTIFYING, poll this same tool with the same ID. |
notification_request_list |
Lists the certified notifications visible to a user. Requires userId (from session_login, session_info or profile_get) — this listing is user-scoped, not case-file-scoped, so it spans every case file unless you filter. Use this to recover a notificationRequestId you no longer have; it is the only way to find one. Returns per notification: ID, code, subject, status, type, sentAt, receiverStats and the owning caseFile. Filter by status or statuses (CREATING, DRAFT, IN_PROCESS, SENT, PARTIALLY_READ, FULLY_READ, PARTIALLY_ANSWERED, FULLY_ANSWERED), by caseFileIds, by search over the subject, or by receiversSearch to find the notification sent to a given recipient. Paginated. |
notification_request_update |
Edits a notification that has not been sent: subject, content, type and language. Requires notificationRequestId and caseFileId. content must be valid HTML — plain text is accepted by the API but does NOT render on the recipient landing page. Supported tags only: , , , |
notification_request_delete |
Deletes a notification. Requires notificationRequestId and caseFileId. There is no undo. TESTED: once the notification has been sent the API rejects this with 403 Forbidden — a sent notification is delivery evidence and cannot be removed. If you only want it filed elsewhere, use notification_request_case_file_move instead. |
notification_request_duplicate |
Creates a new DRAFT notification from an existing one, copying its content, its recipients and its attachments. Works whatever state the original is in, so this is how you resend to the same people or reuse a sent notification as a template. Generate a UUID v4 for ID and supply a new subject; pass caseFileId in the body to place the copy in a different case file, or omit it to keep it alongside the original. THE COPY IS BUILT ASYNCHRONOUSLY: it starts in CREATING with zero recipients and zero documents, and fills in afterwards, so reading it immediately shows an empty notification that is not empty. Poll notification_request_status until the status is DRAFT before inspecting or sending it. Because recipients ARE copied, review them with notification_receiver_list before calling notification_request_send — otherwise you will send to the original list again. |
notification_request_case_file_move |
Moves a notification to a different case file. Note the two caseFileId values: the one in the path is where the notification is NOW, and the one in the body is the destination. Notifications are grouped by case file, and this is the only way to change that grouping without duplicating. |
notification_receiver_list |
Lists a notification's recipients with their individual delivery state. Returns per recipient: ID, firstName, lastName, email, phonePrefix/phoneNumber, status (INVALID, READY_TO_SEND, SENT, READ, ANSWERED, ERROR), statusUpdatedAt, answer once they respond, emailBounced, and validationError (TAKEN, IS_DEFINED, IS_INVALID) for a rejected address. Worth calling before notification_request_send to see whether any address came back INVALID, and after sending to see who read or answered. Also the way to recover a receiverId for notification_certificate_get. Paginated; filterable by ID. |
notification_receiver_update |
Corrects a recipient's details: firstName, lastName, email, phonePrefix, phoneNumber. Requires receiverId, notificationRequestId and caseFileId. Use this to fix a mistyped address rather than deleting and re-adding, which would lose the receiverId. phonePrefix must include the + (for example +34). A phone number is required if the recipient is to receive the RCS/SMS link (sendSmsUrl), the WhatsApp link (sendWaUrl), or an OTP challenge (otpRequired). |
notification_receiver_delete |
Removes a recipient from a notification. Requires receiverId, notificationRequestId and caseFileId. To remove every address the platform rejected in one call, use notification_receiver_invalid_purge rather than deleting them one by one. |
notification_receiver_add_bulk |
Adds several recipients in one call instead of one notification_receiver_add per person. Pass receivers as an array; each entry needs ID (you generate it), firstName, lastName and email, and may carry phonePrefix (with the +) and phoneNumber. Note this bulk form does NOT accept the per-recipient otpRequired, sendWaUrl or sendSmsUrl flags that the single-recipient tool does — set the defaults on the request instead (otpByDefault, sendWaUrlByDefault, sendSmsUrlByDefault). The maximum number of recipients is a per-subscription setting, not a fixed API limit: it varies by tenant and platform, so do not assume a number — add them and read the error if the tenant's cap is exceeded. Add every recipient before calling notification_request_send, then check the result with notification_receiver_list, since a rejected address appears with status INVALID. |
notification_receiver_invalid_purge |
Removes every recipient whose status is INVALID — addresses the platform rejected as malformed or duplicated — from a notification in a single call. Requires notificationRequestId and caseFileId. Recipients in any other status are left untouched. AN INVALID RECIPIENT BLOCKS THE SEND, so run this (or fix the addresses with notification_receiver_update) before notification_request_send, or the notification will not go out. Use notification_receiver_list first to see what will go. |
notification_document_list |
Lists the documents attached to a notification with their processing status, and it is what you poll after notification_document_add: a newly registered document starts at PENDING and reaches READY_TO_SEND in roughly 8 seconds. Calling notification_request_send while any document is still PENDING fails with 409/404 NOTIFICATION_NOT_FOUND. Poll with a bounded retry — every few seconds, a dozen attempts at most. Requires notificationRequestId and caseFileId. Paginated. |
notification_document_delete |
Removes an attachment from a notification. Requires documentId (from notification_document_list), notificationRequestId and caseFileId. |
notification_document_download_url |
Returns { downloadUrl }, a temporary link to an attachment as it was sent. Requires documentId (from notification_document_list), notificationRequestId and caseFileId. Use it to retrieve a file you attached or to verify what a recipient received. The URL is presigned and expires — fetch it when you need it rather than storing it. |
notification_certificate_list |
Lists the delivery certificates already generated for one recipient, so you can reuse one instead of generating a duplicate. Requires receiverId, notificationRequestId and caseFileId. Returns per certificate: ID, status (DRAFT, CERTIFYING, CERTIFIED), language, createdAt, certifiedAt, partial — whether it is an intermediate certificate issued before the recipient finished responding — and embeddedDocuments. Do not read embeddedDocuments as "the package contains the attachments": in a tested run it was false on a notification that had an attachment, and notification_certificate_package_url still returned a ZIP carrying that attachment. Once a certificate is CERTIFIED, download it with notification_certificate_document_url (the certificate alone) or notification_certificate_package_url (a ZIP that also carries the attachments). |
notification_certificate_document_url |
Returns { documentUrl } for the certificate PDF on its own, WITHOUT the attachments. Requires certificateId, receiverId, notificationRequestId and caseFileId. Wait until the certificate is CERTIFIED: generation is asynchronous and the first call can 404 or come back empty while it is still CERTIFYING, so poll a few times with a bounded retry rather than hammering it. If you want the attachments bundled in, use notification_certificate_package_url instead. |
notification_certificate_package_url |
Returns { packageUrl } for a ZIP containing the certificate AND the notification's attachments — the "with annexes" form. There is no separate preview flag anywhere in the API: the package carries the annexes, the document is the certificate alone. Requires certificateId, receiverId, notificationRequestId and caseFileId. Same preconditions as notification_certificate_document_url — wait for CERTIFIED, and expect the first call to fail while generation is still running. |
case_file_create |
Creates a new case file — the top-level container for all related operations (evidence, notifications, signatures, dossiers). Call this first before any other operation. Generate a UUID v4 for ID. Returns caseFileId needed for all subsequent calls. |
case_file_list |
Lists all case files in your EAD Enterprise Suite account. Pass userId (from session_login or session_info) to scope results to your account. Returns paginated list with IDs, names, and status. |
case_file_get |
Retrieves details of a specific case file. Requires: caseFileId. Use to verify a case file exists before creating evidence groups, dossiers, or signature requests. |
case_file_delete |
Deletes a case file and everything filed inside it — evidence groups, dossiers, notifications and their certificates. Irreversible, with no confirmation step and no recycle bin. Requires: caseFileId. Returns no body (HTTP 204); confirm with case_file_list. Do not call it to 'clean up' unless the user asked for that case file to be destroyed. |
session_login |
Force the EAD Enterprise Suite MCP server to re-authenticate. Takes no parameters and accepts no credentials: the server re-exchanges the user key it was configured with (MCP_AUTH_USER_KEY) for a fresh session token, and this tool reports the resulting userId and expiry. The server manages authentication automatically — call this only to force a re-login or after a 401. |
profile_get |
Returns the authenticated user's own profile. It identifies the caller from the session token alone — no email or any other input needed — so it works on every deployment, including a per-request Bearer one. Its ID field IS your userId (UUID): the value required by case_file_list and every /users/{userId}/... operation. Prefer this over session_info when you need the userId: it is the canonical source. Also returns companyId (needed to subscribe to the notifications SSE stream) and defaultCaseFileId. Also returns permit, a set of booleans — { evidences, idVerifications, notifications, chats, signatures } — that says which tool families this account may use at all: a false entry means every tool in that family returns 403 regardless of inputs, and no retry or different argument will help. Read it before calling into a family for the first time; on the integration deployment checked on 2026-09-07, permit.idVerifications was false and every identity tool returned 403 NoIdVerificationsPermit. No parameters. |
use_case_list |
Lists available use cases for the account. Use cases define the allowed signature workflows and document types. Returns useCaseId values needed for signature_request_create. |
id_verification_video_create |
Starts a REMOTE VIDEO identity verification for one person: the platform contacts them and runs the identification session. Requires: ID (UUID v4 you generate), name, firstSurname, email, phonePrefix and phoneNumber. phonePrefix must include the leading + (for example '+34'). secondSurname is optional. Returns HTTP 201 with NO body, so keep the ID you generated — it is the verificationId, and id_verification_list is the only way to read the outcome. PERMIT-GATED: call profile_get first and check permit.idVerifications; if it is false every call here returns 403 with code NoIdVerificationsPermit and no argument change will help, so report it rather than retrying. Presential (in-person) identity verification is deprecated upstream and deliberately not exposed. |
id_verification_list |
Lists the identity verifications belonging to a user, with the outcome of each. Requires: userId (from profile_get). Items are { ID, email, name, firstSurname, secondSurname, status, identificationType, createdAt, createdBy, rejectedReason, rejectedContext }, so this is where you read whether a verification succeeded and, when it did not, why. Supports filter, order and page. This is the only way to observe an id_verification_video_create, which returns no body. PERMIT-GATED: returns 403 with code NoIdVerificationsPermit when profile_get reports permit.idVerifications === false. |
id_verification_contract_url |
Retrieves the signed identity-verification contract for one completed verification. Requires: verificationId — the ID you generated for id_verification_video_create, or an ID from id_verification_list. NOTE: the OpenAPI specification declares a 200 response with NO body for this operation, so the exact payload is undeclared and has not been observed against a working deployment; inspect what comes back rather than assuming a particular field. PERMIT-GATED: returns 403 with code NoIdVerificationsPermit when profile_get reports permit.idVerifications === false. Signing the contract requires two live OTPs and is deliberately not exposed as a tool. |
signature_group_create |
Creates a signing order group for a CONFIGURABLE signature request. Types: 'Document' (groups documents into signing rounds — use its ID as groupId in signature_request_add_document), 'Signatory' (groups signatories into signing rounds — use its ID as groupId in signature_participant_create), 'DocumentSignatory' (links a specific document to a signing round, requires documentId). IMPORTANT — avoid empty groups: when a CONFIGURABLE request is created, the API automatically pre-creates one Document group and one Signatory group both at index:1. Always use these pre-existing index:1 groups for your first document and first signatory (retrieve their IDs with signature_group_list immediately after creating the request). Only call signature_group_create for the ADDITIONAL groups (index:2, 3…). Add participants with linkToAllDocuments:true so DocumentSignatory groups are auto-generated at the correct index. Adding participants without linkToAllDocuments leaves them unlinked to documents and signature_coordinate_set will fail with 'Signatory not found'. |
signature_group_list |
Lists all signing order groups of a CONFIGURABLE signature request. Returns ID, type (Document/Signatory/DocumentSignatory), index, and documentId for each group. Call immediately after signature_request_create to retrieve the pre-created index:1 group IDs before adding documents or participants. |
signature_request_create |
Creates a new signature request in DRAFT status. Requires: case_file_create → caseFileId. Generate a UUID v4 for ID. Set deadline as ISO 8601 datetime (max ~30 days ahead). Returns requestId. Add documents with signature_request_add_document and participants with signature_participant_create before activating. |
signature_request_get |
Retrieves full details of a signature request. Requires: signature_request_create → requestId, case_file_create → caseFileId. Returns status, documents, participants, deadline, and history. Use to check overall process state. |
signature_request_cancel |
Cancels an active signature request. Requires: activate_signature_request (ACTIVE status), requestId, caseFileId. Transitions to CANCELLED. Cannot be undone. |
signature_request_add_document |
Adds a document to a DRAFT signature request. Requires: signature_request_create → requestId, case_file_create → caseFileId. Provide a string ID for the document. Compute SHA-256 hex hash of the PDF before calling. Optional: pass fileUrl (a publicly accessible URL) to have the tool download and upload the file to S3 automatically — no separate PUT needed. If fileUrl is omitted, returns url (presigned S3 upload URL) for manual PUT. Cannot add documents after activate_signature_request is called. For CONFIGURABLE sequence: groupId must reference a Document type group (not Signatory or DocumentSignatory) — passing a wrong group type returns 'Signature group not found'. |
signature_document_list |
Lists the documents of a signature request with a document-level status and per-document statistics. Requires: signature_request_create → requestId, case_file_create → caseFileId. Items are { ID, requestId, groupId, status, title, fileName, fileSize, convertToPdf, participantStats, signatoryStatusStats, signatoryCoordinatesStats } — for example status PARTIALLY_SIGNED with signatoryStatusStats { pending: 0, readyToSign: 1, signed: 1, rejected: 0 } and signatoryCoordinatesStats { defined: 2, missing: 0 } (live-read on INT 2026-09-07). signatoryCoordinatesStats.missing === 0 is the direct check that every required signatory has coordinates before activate_signature_request. Whether this status also reports upload processing for a freshly added document is NOT verified — keep using signature_request_get for that. For the signatories of one document use signature_document_signatory_list. |
signature_document_signatory_list |
Lists the SIGNATORIES of one document in a signature request, with each signatory's status on that document. Requires: signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Items are { ID, groupId, email, firstName, lastName, status, coordinates, uniqueValidator, phonePrefix, phoneNumber, participantStats } and status is PENDING, READY_TO_SIGN, VALIDATING, SIGNED or REJECTED. Each ID is a signatoryId. To check whether the DOCUMENT itself reached READY_TO_SIGN before activate_signature_request, use signature_request_get; after activation poll here until every signatory is SIGNED before signature_certificate_get. |
signature_document_observer_list |
Lists the OBSERVERS of one document in a signature request — participants created with role OBSERVER, who receive a copy but never sign. Requires: signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Items carry only { ID, email, firstName, lastName }: there is deliberately no status field, because an observer has nothing to complete. For the signers of the same document use signature_document_signatory_list. |
signature_signatory_progress_list |
Lists the documents assigned to ONE signatory of a signature request, with that signatory's progress on each. Requires: caseFileId, requestId and signatoryId. The signatoryId is the ID of a participant whose role is SIGNATORY — read it from signature_participant_list or signature_document_signatory_list. Passing a participant ID whose role is not SIGNATORY returns 404 'Signatory not found' — observed on INT 2026-09-07 with a VALIDATOR ID; it is one ID space, but the signatory-scoped endpoints accept only the ids of SIGNATORY participants. Returns { data, meta.totalElements } with items { ID, fileName, fileSize, status }, where status is PENDING, READY_TO_SIGN, SIGNED or REJECTED. |
signature_participant_create |
Adds one participant to a DRAFT signature request. This is the ONLY participant create endpoint: role selects SIGNATORY (must sign), OBSERVER (receives a read-only copy) or VALIDATOR (must approve before its signatory can sign). Requires: signature_request_create → requestId, case_file_create → caseFileId, plus role, firstName, lastName and email. YOU generate ID (UUID v4) and the call returns HTTP 201 with NO body, so nothing is handed back — the ID you generated IS the participantId, and it is the signatoryId if you passed role SIGNATORY or the validatorId if you passed role VALIDATOR. Keep it. For ADVANCED signatures phonePrefix and phoneNumber are mandatory because the signer receives the OTP there, and WhatsApp delivery is NOT supported for ADVANCED; for INTERPOSITION phone is optional and WhatsApp is available when the platform is configured for it. Add at least one SIGNATORY before activating. For role VALIDATOR do NOT include groupId or linkToAllDocuments — link it afterwards with assign_validator_to_signatory. Use signature_participant_add_bulk to add many at once, and signature_participant_list to re-read what exists. |
signature_participant_add_bulk |
Adds many participants to a DRAFT signature request in one call instead of one signature_participant_create per person. Requires: signature_request_create → requestId, case_file_create → caseFileId, and a participants array whose entries take the same fields as signature_participant_create, including the ID and role you generate for each. Mixed roles in one call are allowed. Returns HTTP 201 with NO body, so keep the ids you minted and re-read the result with signature_participant_list. |
signature_participant_list |
Lists every participant of a signature request with the role each was created under — SIGNATORY, OBSERVER or VALIDATOR — plus contact details and validity. Requires: signature_request_create → requestId, case_file_create → caseFileId. Items are { ID, requestId, groupId, role, firstName, lastName, email, phonePrefix, phoneNumber, createdAt, editable, emailBounced, valid, validationError, participantStats, documentStats }. This is the tool that resolves ids: an item's ID is the participantId, and it is also the signatoryId when role is SIGNATORY and the validatorId when role is VALIDATOR. Supports filter, order and page. |
signature_participant_update |
Corrects a participant's details before the signature request is activated. Requires: signature_participant_create → participantId, signature_request_create → requestId, case_file_create → caseFileId. Any of groupId, firstName, lastName, email, phonePrefix and phoneNumber may be sent. The role CANNOT be changed, so to turn a signatory into an observer, delete it and create it again. Use this to repair a bounced or mistyped email — signature_participant_list reports emailBounced and validationError. Returns no body; confirm with signature_participant_list. |
signature_participant_delete |
Removes one participant from a signature request. Requires: signature_participant_create → participantId, signature_request_create → requestId, case_file_create → caseFileId. Use it to drop someone added by mistake, or to change a role (delete, then create again with the new role, since role is not updatable). Returns no body; confirm with signature_participant_list. To drop every invalid participant at once use signature_participant_invalid_purge instead. |
signature_participant_invalid_purge |
Removes every participant of a signature request that the platform has marked invalid, in one call. Requires: signature_request_create → requestId, case_file_create → caseFileId. signature_participant_list identifies them via valid: false and validationError — typically an undeliverable email or a malformed phone number. Returns no body; confirm with signature_participant_list. Prefer signature_participant_update when the detail can be repaired rather than the person dropped. |
assign_validator_to_signatory |
Assigns one or more validators to a specific signatory in a signature request. The validator must approve before the signatory can sign. Requires: signature_participant_create (validator) → validatorId in validatorIds array, signature_participant_create (signatory) → signatoryId, signature_request_create → requestId, case_file_create → caseFileId. |
signature_validator_list |
Lists the validators currently linked to ONE signatory of a signature request. Requires: signature_participant_create (signatory) → signatoryId, signature_request_create → requestId, case_file_create → caseFileId. Items carry { ID, email, firstName, lastName }, where each ID is a validatorId. Note the two-step model: creating a participant with role VALIDATOR does not attach it to anyone, so a validator can exist on the request and not appear here until assign_validator_to_signatory links it — an empty list means nothing is linked yet, not that no validator exists. |
signature_validator_unassign |
Unlinks one validator from one signatory, reversing assign_validator_to_signatory. Requires: signature_validator_list → validatorId, signature_participant_create (signatory) → signatoryId, signature_request_create → requestId, case_file_create → caseFileId. This removes the LINK only: the validator remains a participant of the request, so use signature_participant_delete to remove the person entirely. Returns no body; confirm with signature_validator_list. |
activate_signature_request |
Activates a signature request, transitioning from DRAFT to ACTIVE and sending signing invitations to all signatories. Do NOT call this immediately after uploading files. Activation preconditions: request is DRAFT; at least one SIGNATORY exists; every document has been uploaded to its presigned URL; backend processing has had time to complete for every uploaded document (use processed/READY_TO_SIGN from signature_request_get when exposed; otherwise wait after the successful PUT); and PDF documents have signature coordinates set for every required signatory. INTERPOSITION may send a simple signing link, including WhatsApp when available/configured; ADVANCED uses phonePrefix/phoneNumber for OTP and currently does not support WhatsApp delivery. IRREVERSIBLE: cannot add documents or participants after activation. ASYNC: after activation, poll signature_request_get until status is ACTIVE, then use signature_document_signatory_list with documentId to monitor each signatory, or signature_document_list for the request's documents and their aggregate signatoryStatusStats; call signature_certificate_get only after the document is SIGNED. |
signature_coordinate_set |
Sets the visual position of the signature field on a PDF document page. Required for PDF documents before activation, for both INTERPOSITION and ADVANCED signatures. Requires: signature_participant_create → signatoryId, signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Provide coordinates as array of {page (1-based), x (points from left), y (points from bottom)}. Set coordinates after the document has been uploaded and before activate_signature_request. |
signature_certificate_get |
Retrieves the signed document certificate PDF. Requires: activate_signature_request (document fully SIGNED), signature_request_add_document → documentId, signature_request_create → requestId, case_file_create → caseFileId. Returns documentUrl (signed PDF certificate). ASYNC: poll until documentUrl is available. |
large_evidence_upload_initiate |
Performs the large_evidence_upload_initiate operation against the GoCertius API. Review the API documentation for full field details. |
large_evidence_upload_complete |
Finalize a multipart evidence upload and register the evidence in the group. Returns immediately — the evidence transitions asynchronously to COMPLETED. Poll evidence_list until status is COMPLETED before sealing the group. |
large_evidence_upload_get |
Reports how much of a large evidence upload the platform has actually received. Requires: caseFileId, evidenceGroupId and the evidence ID. Returns fileName, totalSizeMB, chunkSizeMB and biggestUploadedOffset — compare biggestUploadedOffset against totalSizeMB to decide whether every part landed before calling large_evidence_upload_complete. Use it to resume or diagnose a stalled upload. |
Credentials
This node requires a "EAD Enterprise Suite API" credential with the following fields:
| Field | Description | Required? | Secret? |
|---|---|---|---|
API Base URL |
Upstream API root. Required: your user key is exchanged for a session token against this host, and the server will not start without it. | yes | no |
MCP_AUTH_USER_KEY |
Long-lived EAD Enterprise Suite user key, exchanged automatically for a short-lived session token. Use it for headless or automated access instead of an account password. (See https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/ for credential acquisition.) | yes | yes |
Need credentials? Sign up or log in at https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/.
Upgrading from 1.x
Re-create the credential — editing the existing one is not enough. The credential
form changed shape. It now has exactly two required fields:
| Field | Value |
|---|---|
API Base URL (MCP_API_BASE_URL) |
The EAD Enterprise Suite API root you connect to. No longer optional. |
User Key (MCP_AUTH_USER_KEY) |
Your long-lived user key. Replaces the e-mail/password pair. |
Delete the old EAD Enterprise Suite API credential, create a new one, and re-select it
on every node that used it. Saved workflows keep working once the new credential is
selected.
Two operations changed target, and both lost their Document Id input. This one is
not fixed by re-selecting a credential — any saved workflow using either operation has
to be re-pointed by hand:
| Operation | Now lists | Use instead, for the old behaviour |
|---|---|---|
| Signature Document List | the documents of a signature request | Signature Document Signatory List |
| Signature Participant List | the participants of a signature request | Signature Document Observer List |
The Document Id field is gone from both. The two replacements are new operations in
this release and still take it.
Signature Participant Create hands back a different field. The call answers 201 with
no body, so the connector injects the id you supplied into the output item. It used to
inject it as signatoryId whatever Role you had selected — which was only ever true for
a signatory. It now injects participantId for every role, and adds the role-specific
name on top:
| Role you select | Fields on the output item |
|---|---|
| Signatory | participantId and signatoryId |
| Validator | participantId and validatorId |
| Observer | participantId |
A saved workflow that reads $json.signatoryId after creating a Signatory is
unaffected. One that reads it after creating a Validator or an Observer was
reading a field that never described what it held, and now reads nothing: re-point it at$json.participantId, or at $json.validatorId for a validator.
82 operations, up from 50. Apart from the three changes above, every operation that
existed before keeps its name, its inputs and the fields it hands back; the rest are
additions.
The two one-call notification helpers are not in the connector. They carry no REST
annotation upstream, so they are absent by design — chain the individual notification
steps instead. All of those are present.
Use as an AI Agent tool
This node is flagged usableAsTool: true, so any n8n AI Agent (n8n ≥ 1.79.0) can consume it dynamically: drag it into the workflow and wire its main output to an AI Agent's "Tool" input.
For best results pair with an AI Agent node running V2 — V3 has a known empty-tool-response bug in some recent n8n versions (see n8n issue #26202).
License
MIT. See LICENSE.