TillyGen and Zapier

What this is about

Zapier chains a trigger to actions across thousands of apps, and its webhook trigger is the open door for tools without a prebuilt connector. That is the route for TillyGen: a plan event reaches Zapier as a webhook call carrying JSON, and the Zap fans it out — a Slack message to the production channel, a row in a tracking sheet, an email to the client contact. The setup is clicking, not coding, which puts it within reach of the producer who owns the process. The plan itself never moves; only news about it does.

An integration is good when nobody talks about it any more: the data is where it is needed and nobody exports anything.

What runs differently here

In planning terms, that means:

• A webhook trigger receives plan events from the TillyGen API and starts the Zap with the event's fields available as variables
• Typical first Zap: schedule updated, therefore post to the production's Slack channel with the change summary and plan link
• A logging Zap appends every export event to a spreadsheet — a free audit trail of who published which plan state when
• One Zap per chore keeps failures isolated; a broken mail step never blocks the Slack announcement

Step by step

This order gets you there fastest:

1. List the chores that repeat around every plan change — announcements, logs, notifications — and pick the one that annoys most.
2. Create a Zap with a webhook trigger and point the TillyGen API's event at its catch URL, then fire a test event to see the fields.
3. Map the event fields into the action — channel message, sheet row, email — and phrase the output so a human recognizes what changed.
4. Turn the Zap on and watch it across one real planning week; adjust wording and filters where it fires too often or too vaguely.
5. Add the next chore as its own Zap instead of growing the first one — small Zaps survive, clever ones rot.

Common pitfalls

What most often goes wrong in practice:

• A Zap that posts on every minor edit trains the channel to ignore plan announcements entirely — filter for meaningful events
• Automation hides authorship: if the Zap posts wrong information, someone must own noticing it — a robot has no shame

With TillyGen

TillyGen stays the system where plans change; Zapier is the town crier that tells everyone. The API emits the event, the Zap spreads the word, and no tool downstream ever holds the master copy.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.