TillyGen and n8n

What this is about

n8n is workflow automation you can host yourself: nodes on a canvas, an HTTP Request node for any API, a code node for the logic no prebuilt block covers. For production companies working with pharma, banking or unannounced products, that self-hosting is the entire argument — briefing contents and client identities never leave their own machines. Against the TillyGen API, n8n does what the cloud automators do: receive plan events by webhook, fetch plan state on a schedule, push messages and rows into the systems around the production. The difference is where it happens.

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

Where this differs from the general case:

• The HTTP Request node authenticates against the TillyGen API with stored credentials and handles both fetching state and receiving webhooks
• A code node covers production-specific logic — custom severity rules, naming schemes — without waiting for anyone to build a connector
• Self-hosting keeps event payloads with client names and project titles inside your own network perimeter
• Workflows export as JSON files, so the automation itself is versionable in the company git like any other asset

Step by step

This order gets you there fastest:

1. Stand up n8n on your own server or the company's existing container host, and secure it before the first credential gets stored.
2. Store the TillyGen API credentials in n8n's credential vault, then verify the connection with a plain read call in an HTTP Request node.
3. Build the first workflow around a webhook node: plan event in, severity checked, message out to the channel your crew actually reads.
4. Add a code node where prebuilt logic falls short — formatting call times, mapping department names — and keep that code short.
5. Export the finished workflow as JSON into the company repository, so the automation survives server moves and personnel changes.
6. Monitor the execution list weekly at first; self-hosted also means self-noticed when something silently stops.

Common pitfalls

What most often goes wrong in practice:

• The instance nobody maintains: an update postponed for a year, and the automation dies the week three productions depend on it
• Credentials copied into code nodes instead of the vault — the workflow JSON now leaks secrets into every export and backup

With TillyGen

n8n moves information about the plan through your own machines; the plan itself stays in TillyGen. The API is the single doorway between the two, and everything behind that doorway is yours to govern.

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.