ShotGrid Event Daemon vs Webhooks: Choose an Automation Path

The decision: react to ShotGrid changes without blocking users

Your studio needs to run a pipeline task whenever an artist publishes a version, updates a shot status, or changes a custom field. ShotGrid does not provide a synchronous hook that can stop or delay a save inside the application. You must choose an asynchronous automation path: the self-hosted ShotGrid Event Daemon or cloud-originated webhooks.

Useful takeaway: choose Event Daemon when your pipeline runs on persistent on-premise infrastructure and needs direct access to local file systems or DCC applications. Choose webhooks when you run cloud-native endpoints, serverless functions, or CI/CD triggers and want to avoid polling. Both run after the change is committed, so neither can validate or block the user's action in real time.

Constraints and assumptions

• You administer a ShotGrid site or have permission to manage site preferences and API scripts.
• You are not trying to block entity saves or enforce real-time validation inside ShotGrid.
• You can run a test in a staging project before changing production site preferences.
• Behavior depends on your ShotGrid release; confirm current API support in Autodesk documentation before production use.

Supported options compared

Factor	ShotGrid Event Daemon	ShotGrid webhooks
Hosting model	Self-hosted Python service, usually on-premise	HTTPS endpoint you operate, called by ShotGrid
Delivery mechanism	Polls ShotGrid for changes, then runs registered callbacks	HTTP POST JSON payload on matching entity events
Best suited to	Local file-system access, DCC launches, multi-step Python jobs	Lightweight notifications, serverless functions, CI/CD triggers
Execution environment	Trusted Python process with ShotGrid Python API	External language or runtime; JSON payload only
Filtering	Entity type, changed fields, project, user	Entity type, changed fields, project, user
Blocking behavior	Asynchronous; cannot block user saves	Asynchronous; cannot block user saves

Trade-offs

Event Daemon

The Event Daemon is a long-running Python process that polls ShotGrid and executes callbacks in the same trust boundary as your pipeline tools. It can launch local applications, read mounted file systems, and use the ShotGrid Python API directly. The cost is operational: you must manage the process, keep Python dependencies current, rotate API keys, and handle callback failures yourself.

Webhooks

Webhooks remove polling by pushing JSON events to an endpoint you expose over HTTPS. This fits serverless platforms and cloud functions, but the endpoint must be publicly reachable, handle ShotGrid delivery retries and timeouts, and optionally validate that the request originated from ShotGrid. You also must parse the payload and call the ShotGrid API back if you need full entity data.

Concrete implementation: register a webhook and confirm delivery

This example registers a webhook for asset creation in a staging project. Replace all placeholders with your own values. Run the listener on a host you control; run the registration script from a workstation with network access to your ShotGrid site.

1. Run a temporary HTTPS listener

Where to run: a public host or cloud function reachable by ShotGrid. Required permissions: ability to bind to port 443 or configure a cloud trigger. Risk: an unvalidated endpoint can accept arbitrary POSTs; restrict by source IP or validate ShotGrid signatures if your release supports it.

# Conceptual listener; do not copy into production without authentication
from http.server import BaseHTTPRequestHandler, HTTPServer
import json

class HookHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(length)
        try:
            payload = json.loads(body)
            print(json.dumps(payload, indent=2))
        except Exception as exc:
            print('Invalid JSON:', exc)
        self.send_response(200)
        self.end_headers()

HTTPServer(('0.0.0.0', 443), HookHandler).serve_forever()

Expected check: the listener process starts and binds to the port without permission errors.

2. Register the webhook through the ShotGrid Python API

Where to run: a workstation or CI runner with the ShotGrid Python API installed. Required permissions: ShotGrid API script key with webhook management rights on the target site. Placeholders: SHOTGRID_SITE, SCRIPT_NAME, API_KEY, PROJECT_ID, WEBHOOK_URL.

import shotgun_api3

sg = shotgun_api3.Shotgun(
    'https://SHOTGRID_SITE.shotgrid.autodesk.com',
    script_name='SCRIPT_NAME',
    api_key='API_KEY'
)

webhook = sg.create('WebhookRegistration', {
    'entity_type': 'Asset',
    'event_type': 'created',
    'project': {'type': 'Project', 'id': PROJECT_ID},
    'url': 'WEBHOOK_URL',
    'description': 'Staging asset creation test'
})
print(webhook)

Expected check: the API returns a WebhookRegistration record with an ID. Confirm the registration appears in ShotGrid site preferences under Webhooks.

3. Trigger and inspect delivery

Create a test asset in the staging project. Expected check: the listener receives an HTTP POST with a JSON payload containing a meta block and entity information. If nothing arrives, check the ShotGrid webhook delivery log, endpoint reachability, and firewall rules.

Cleanup

Remove the test registration so it does not fire in staging after validation:

sg.delete('WebhookRegistration', webhook['id'])

Expected check: the registration no longer appears in ShotGrid webhook preferences.

Limitations

• Neither mechanism blocks or rolls back a user's ShotGrid action; both are post-change handlers.
• Event Daemon requires dedicated process monitoring and Python dependency upkeep.
• Webhook endpoints must be publicly reachable over HTTPS and must absorb delivery retries without duplicating pipeline work.
• Feature behavior, SDK versions, and deprecation status vary by ShotGrid release; verify against current Autodesk documentation before production deployment.

Practical verification

1. Deploy the listener and registration in a staging project only.
2. Create, update, and delete test entities matching your filters.
3. Confirm payloads arrive, measure end-to-end latency, and confirm failure handling when the listener is temporarily stopped.
4. Review current Autodesk ShotGrid release notes for Event Daemon or webhook changes before enabling in production.