Guides

    Exports and automations

    Export policies decide whether a document may be downloaded or delivered; automations react to document events and deliver files to your systems.

    Exporting is governed by your organization, not by the caller. An export policy decides, for each document, whether it may be downloaded, delivered to configured destinations, or both, and what validation it needs first. The same policy applies to the editor, embeds, REST and MCP.

    With no matching published policy, export is blocked everywhere. An organization admin publishes its first policy in Automatizaciones; none is created by default.

    The flow

    Prepare a proposal

    POST /api/documents/{documentId}/export-proposals returns what the policy allows right now:

    proposal
    {
      "id": "6f0c…",
      "policy": {
        "id": "…",
        "revision": 3,
        "name": "Descarga tras validar",
        "mode": "download_only",
        "validation": "no_errors"
      },
      "formats": ["pdf", "docx", "zip"],
      "destinations": [],
      "validation": { "status": "cached", "errors": [], "warnings": [] }
    }

    One-shot generation already returns one as exportProposal (or exportBlockedReason).

    Confirm it

    POST /api/documents/{documentId}/export-runs with { "proposalId", "action": "download" } — or "deliver" to send it to the policy's destinations. A proposal is bound to the exact document revision and policy: if either changed, prepare a new one (409). Identical requests share one export run; pass "resend": true to deliver again.

    Wait and download

    Poll GET /api/documents/{documentId}/export-runs/{runId} until status is ready (failed, expired and cancelled are final). When downloadAllowed is true, fetch GET …/export-runs/{runId}/pdf (or docx, zip).

    The quickstart has the full code in curl and JavaScript. Over MCP, export_document exposes the same prepare, execute, status and download operations.

    Previews are separate: the editor's render view and POST …/exports with preview-pdf are always available and grant no download. The template's Word format defines layout, headers and styles; it does not grant permission to export.

    Policies

    The first matching policy by priority applies. A policy can be:

    modeEffect
    download_onlyThe file can be downloaded.
    optional_deliveryThe person exporting chooses download or delivery.
    required_deliveryThe file goes to the destinations; downloading is refused.
    delivery_and_downloadDelivered, and also downloadable whatever the delivery outcome.

    Conditions can look at the template, integration metadata, form values and validation. The policy's validation is allow_findings, no_errors (a current review without errors) or no_findings (no errors or warnings) — it never generates or repairs content.

    Automations

    Automations react to events — a document created, updated (debounced: 10 s of inactivity, at most 60 s), deleted or exported; a template created, published or deleted — and run steps in order: HTTPS requests, HTTPS file delivery, SFTP or S3-compatible storage. Mappings read event, document and form values and the output of earlier steps. Credentials are encrypted and write-only.

    • Draft → simulate → publish. Rules are drafts until published; simulation runs without side effects.
    • Retries. Temporary failures retry for up to 24 hours, keeping successful steps. Unknown outcomes wait for an admin to resolve them instead of being retried blindly.
    • History. Every execution is kept with its steps and sanitized results.

    Manage them in the app, over REST (/api/automations/*, scopes automations:read, automations:manage, automations:execute) or over MCP (create_automation_rule, simulate_automation_rule, publish_automation_rule, …). The API reference lists every endpoint.