ShotGrid Automation: Webhooks vs. Event Daemon Decision Guide

The decision: react to entity changes without polling

When a Version status changes from pending to approved, your pipeline often needs to trigger downstream work immediately. Polling the ShotGrid REST API from a cron job wastes requests and adds latency. ShotGrid supports two event-driven paths: webhooks and the Event Daemon. The useful takeaway is simple: use webhooks for lightweight, cloud-native reactions to entity changes, and use the Event Daemon when you need full shotgun_api3 access, deterministic retries, or on-premise processing.

Constraints and prerequisites

Both paths assume an active ShotGrid site and API script credentials. Webhooks additionally require a public HTTPS callback endpoint that ShotGrid can reach. The Event Daemon requires a dedicated host with a Python runtime and network access to ShotGrid. Before you invest in either path, confirm that the entity and field you want to monitor actually emit events in your ShotGrid schema; custom entities or fields may not produce expected events unless the event configuration supports them.

Comparing supported options

Dimension	Webhooks	Event Daemon
Delivery model	ShotGrid POSTs a JSON payload to your HTTPS callback	Persistent Python process polls the ShotGrid event log
Infrastructure	No polling host; any HTTPS-capable service works	Dedicated host with Python and outbound network access
API access	Limited to the delivered payload; no direct API session	Full shotgun_api3 read/write access
Retry behavior	Limited built-in retry; deliveries may repeat or arrive out of order	Local queueing; deterministic processing order
Operations	Expose a public endpoint; validate authenticity	Store credentials; monitor daemon and event log
Best for	SaaS integrations, lightweight notifications	Complex workflows, on-premise processing, auditable writes

Trade-offs in practice

Webhooks lower infrastructure burden but expose an endpoint and rely on ShotGrid delivery. Because retries or duplicate events can occur, receivers must be idempotent: processing the same payload twice should not create duplicate side effects. Validate authenticity using ShotGrid-provided tokens or signatures where available; confirm the exact mechanism in current documentation because verification methods can change.

The Event Daemon gives reliable, auditable processing but requires credential storage, server maintenance, and event-log monitoring. Plugins inherit the API script's privileges, so avoid over-scoped credentials in production. A dedicated host also means you own patching, logging, and restart behavior.

Concrete validation: testing a Version status webhook

Validate in a sandbox project before enabling production automation. Create a temporary API script key with the least privilege needed to read the relevant entity and register webhooks.

1. In ShotGrid Admin, open the webhook settings and register a new webhook for Version status change events. Confirm the webhook appears in the settings list.
2. Deploy a minimal HTTPS receiver. The example below runs on any HTTPS-capable host or serverless function. Replace <YOUR_SECRET_TOKEN> with the value ShotGrid provides, if applicable.

# Run on your HTTPS server or serverless platform.
# Requires: Python 3, flask, and a TLS-terminated endpoint.
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/shotgrid-webhook", methods=["POST"])
def handle_event():
    # Validate authenticity if ShotGrid provides a token or signature.
    # Confirm the exact header and algorithm in current documentation.
    token = request.headers.get("X-ShotGrid-Token", "")
    if token != "<YOUR_SECRET_TOKEN>":
        return jsonify({"error": "unauthorized"}), 401

    payload = request.get_json(force=True)
    # Log the raw payload for inspection; do not trust field order.
    app.logger.info("Received event: %s", payload)

    # Make processing idempotent: check payload["id"] or event UUID
    # before performing side effects.
    return jsonify({"status": "ok"}), 200

if __name__ == "__main__":
    # In production, run behind a production WSGI server with TLS.
    app.run(host="0.0.0.0", port=8443)

1. Trigger a Version status change in the sandbox project.
2. Expected checks: your receiver logs the payload, and the ShotGrid webhook delivery logs show a successful POST. If the endpoint is unreachable or returns an error, review the delivery logs for retry attempts.

Risks: the callback endpoint is publicly reachable; unauthenticated or replayed deliveries can occur if you skip token validation. After testing, remove the temporary webhook registration and rotate the API script key.

Concrete validation: running an Event Daemon plugin against a copied event

On the dedicated daemon host, use a Python process with shotgun_api3 to poll events. Test with a temporary API script key in a non-production project before enabling production automation.

1. Configure the daemon to connect using the temporary script credentials. Run the process as a service account with write access only to the fields the plugin will update.
2. Start with a sample plugin that listens for the same Version status event, copies the event data, and performs a single field update. Inspect the daemon logs to confirm the plugin processed the intended event.
3. Expected checks: the daemon log shows the event was consumed, and the shotgun_api3 response confirms the expected field write. If the plugin does not fire, verify that the event type and entity are supported by your ShotGrid event configuration.

Risks: the plugin operates with the full privileges of the API script. Over-scoped credentials can lead to unintended writes. Monitor the event log and daemon output for silent failures. When validation is complete, stop the daemon and revoke the temporary script key.

Limitations and current verification requirements

This guide reflects well-established ShotGrid behavior, but exact webhook signature headers, retry counts, timeout windows, and Event Daemon packaging details should be verified against current ShotGrid documentation before production use. Custom entities or field changes may not emit expected events unless the ShotGrid schema and event configuration support them. Treat the validation steps above as a conservative starting point and confirm current behavior in your site.