Skip to main content
A webhook trigger gives your script its own URL. When something sends a request to that URL, Script.it runs your script. Any service that can call a webhook — Zapier, Make, Stripe, your own internal tool — can start your automation this way, and can send data along with it.

​
Creating a webhook trigger

1

Open the Triggers tab

Open the script you want to run, click the Triggers tab, then click Add Trigger.
2

Choose Webhook

Give it a name that says where the calls will come from — “Stripe payment received”, “Deploy finished” — and choose Webhook.
3

Choose the script

Pick the script to run, and fill in any inputs it needs.
4

Create the trigger

Click Create Trigger. Script.it shows you the webhook URL and a signing secret, along with example code for sending a request. Copy them — you’ll need them to set up the sending service.
5

Point your service at the URL

Paste the URL into whatever should call it. Most services have a Send test event button — use it, and check that the run shows up on your trigger.

​
Securing your webhook

Webhook triggers are signed by default. Script.it creates a signing secret when you make the trigger and checks every incoming request against it, so knowing the URL isn’t enough to run your script. The example code shown after you create the trigger already includes the signing, so you can copy it straight into your own service.

​
Using a provider’s own signing

If the calls come from a service that signs its own webhooks — Stripe, Slack, GitHub, Shopify, Zoom, HubSpot, Jira, Trello, Asana, Discord, Zendesk, Intercom, Linear, monday.com, SendGrid, Square, Paddle, Figma, Lemon Squeezy, WhatsApp — choose that provider on the trigger and paste in the secret it gives you. Script.it then checks requests the way that provider signs them, so you can point the service straight at your URL with nothing in between. Some providers also do a one-time verification handshake when you add the URL. Script.it answers it for you, and shows you a verification token when a provider needs one pasted in.

​
Rotating the secret

Clear the signing secret field and Script.it issues a new one. The URL stays the same, so you only have to update the sending service — no need to delete and rebuild the trigger.
You can turn signature checking off if the service calling you can’t sign its requests. If you do, the URL becomes the only thing protecting the trigger — treat it like a password. Don’t share it publicly, commit it to a repository, or put it in client-side code. If it leaks, delete the trigger and create a new one to get a fresh URL.

​
Sending data to your script

Whatever you send in the request body is handed to your script when it runs — a Stripe event, a GitHub push, or any JSON you choose. Your script can read those values and act on them.

​
What happens when the webhook fires

Script.it accepts the request straight away and runs your script right after, so a slow script never causes a timeout on the sending side. Runs appear in your session history like any other run, and in the trigger’s run history on the script. See Managing triggers.

​
Managing webhook triggers

  • Turn it off and on from the script. The URL is kept, so turning it back on resumes with the same setup.
  • Delete it to permanently invalidate the URL. Anything still calling it stops working, and a new trigger gets a different URL.
If you want to react to something in an app you’ve already connected — a Slack message, a GitHub pull request, a Stripe payment — you usually don’t need a webhook trigger at all. Use an app event instead and skip the setup.