ZettaSend Webhooks

Workspace webhooks let you run your own logic on every ZettaSend transfer. A workspace administrator configures an endpoint URL, and the desktop app calls it twice for every transfer that arrives in the workspace: once before it starts, where you can run your own validation rules and approve or reject the transfer, and once after it completes, where you can trigger your own post-transfer pipeline. Your endpoint can return markdown error messages that are shown inside the app on both ends.

Overview

The webhook is a plain POST request with a JSON body. No SDK or special client is required, any HTTP server can receive it. The request carries transfer metadata only (emails, file names, sizes, paths, timestamps). File contents never leave the encrypted peer-to-peer channel and are never sent to your endpoint.

• One endpoint URL per workspace, configured by the administrator.
• Webhooks always run on the receiver's machine. The receiver's workspace settings decide whether a transfer is gated.
• Two calls per transfer: a pre-transfer call before it starts and a post-transfer call after it completes.
• The pre-transfer hook is a hard gate: unless it approves the transfer, the transfer does not happen.

Configuration

1. Sign in to the Team Admin Dashboard (Team plan required).
2. Go to Workspace Settings → Webhook Endpoint.
3. Enter the full URL of your endpoint, e.g. https://example.com/hooks/zettasend.
4. Save. Leave the field empty to disable webhooks.

The URL applies to every workspace member automatically. The receiver's desktop app must be able to reach the URL over the network. The app refreshes workspace settings periodically, so a URL change is picked up automatically without a manual restart.

Hook types

Error messages are always shown on both ends, for both hook types. The sender sees the markdown explanation in their app when a transfer is rejected, and the receiver sees it on their side too.

Request format

The app sends POST to your configured URL with Content-Type: application/json; charset=utf-8. The only headers sent are Host, Content-Type and Content-Length, no authentication headers. Treat the endpoint as public and protect it yourself (for example a secret token in the URL path or an IP allowlist).

Example payload

A daily delivery from a production house to a VFX studio: two DPX sequences plus their reference movs, nested inside a per-episode folder.

{
  "webhook_type": "pre",
  "sender_email": "[email protected]",
  "receiver_email": "[email protected]",
  "file_count": 4,
  "total_bytes": 2182348800,
  "occurred_at_utc": "2026-08-31T22:04:45.6421905+00:00",
  "destination_path": "D:\\VFX\\Incoming",
  "manifest": {
    "files": [
      {
        "relative_path": "ep101\\sc010_010_v001.dpx",
        "length": 892715008
      },
      {
        "relative_path": "ep101\\sc010_020_v001.dpx",
        "length": 892715008
      },
      {
        "relative_path": "ep101\\sc010_010_v001.mov",
        "length": 298844160
      },
      {
        "relative_path": "ep101\\plates\\plate_101_10.mov",
        "length": 98074624
      }
    ]
  }
}

Fields

Assembling full paths

Join destination_path + relative_path to reconstruct the file's location on the receiver's disk. Folder hierarchies are preserved.

Response format

Return a verdict as JSON. A reject can carry an error field with Markdown, which is rendered inside the app on both ends (headings, bold, lists, code, and links are supported).

Accept

{
  "status": "accept"
}

Reject with explanation

{
  "status": "reject",
  "error": "## Naming convention violation\n\nThe following files do not match the\n`sc###_###_v###` convention:\n\n- `ep101\\sc010_010_v001.dpx`"
}

Rejecting without an error field (or with an empty one) produces a generic rejection with no explanation shown.

How the app interprets your response

Timeouts

Delivery failures (connect timeout, non-2xx, unparseable body):

• Pre-transfer: the transfer is blocked. Fail-closed by design, since no approval was given.
• Post-transfer: the transfer already completed; an error is surfaced to both ends.

Example receiver

A Flask receiver with example post-production logic. The pre-transfer hook enforces the studio's shot naming convention and rejects anything that doesn't match. The post-transfer hook logs the delivery and is the place to kick off downstream automation. Any language or framework works, it's just a JSON POST.

import re
from pathlib import Path

from flask import Flask, request, jsonify

app = Flask(__name__)

# Studio convention: every file must start with a shot name like sc010_010_v001
SHOT_PATTERN = re.compile(r"^sc\d{3}_\d{3}_v\d{3}\.")


@app.route("/zettasend/transfers", methods=["POST"])
def transfers():
    payload = request.get_json()
    dest = Path(payload["destination_path"])
    files = payload["manifest"]["files"]

    if payload["webhook_type"] == "pre":
        # Sanity checks run before the transfer may start
        bad = [f["relative_path"] for f in files if not SHOT_PATTERN.match(f["relative_path"])]
        if bad:
            names = "\n".join("- `%s`" % f for f in bad)
            return jsonify({
                "status": "reject",
                "error": "## Naming convention violation\n\n"
                         "These files do not match `sc###_###_v###`:\n\n%s\n\n"
                         "Re-export with correct shot names and resend." % names
            }), 200
        return jsonify({"status": "accept"}), 200

    # Post-transfer: all files are verified on disk, delivery is complete
    delivered = [dest / f["relative_path"] for f in files]
    print("[delivery] %d files written under %s" % (len(delivered), dest))
    # Trigger downstream work here, e.g. register the delivery in your asset DB
    return jsonify({"status": "accept"}), 200

Troubleshooting

If you run into any other problems, email us at [email protected]. For faster diagnostics, open Settings → See Debug Logs in the desktop app and attach the most recent log file to your message.