Gorgias Webhooks & HTTP Integration Explained

Webhooks in Gorgias are called HTTP Integrations

If you go looking for a menu item labeled "Webhooks," you won't find it. Gorgias bundles both directions of the exchange — outbound event notifications and outbound API calls — under one name. Per the Gorgias HTTP Integrations documentation, the feature lets Gorgias "send and fetch data over HTTP" and lets you "subscribe to Gorgias webhooks to trigger API calls" to a third-party endpoint.

In practice there are two things you'll build here:

1. An event webhook — Gorgias fires an HTTP request to your URL when a ticket is created, updated, or gets a new message. This is the classic webhook: your system finds out about a change without polling.
2. A sidebar/data integration — Gorgias calls an external API and displays the JSON it gets back inside the ticket, so agents see a customer's last order or lifetime value without leaving the conversation.

Both are configured in the same place, which is worth seeing before you build anything.

Where to find it and how to add one

The path, verbatim from the docs: open the Settings icon (bottom-left) → Account → HTTP integration → Manage tab, then click Add HTTP integration.

Each integration asks for a small, predictable set of fields:

• Integration name — a label you'll reference later (from Rules, and in the sidebar).
• URL — the third-party endpoint Gorgias will call.
• HTTP method — GET, POST, PUT, or DELETE.
• Request content type — application/json or application/x-www-form-urlencoded for any non-GET method.
• Authentication — either header-based key/value pairs (e.g. an Authorization header) or OAuth2, where you supply a Token URL, Client ID, Client Secret, token location, and token key.

That's the whole contract. Gorgias doesn't sign payloads with an HMAC secret the way some platforms do, so if your endpoint is public you'll want to protect it with a header token you set here and verify on your side.

The payload: template variables are the real lever

The most important thing to understand about a Gorgias webhook is that you decide what's in it. Gorgias exposes template variables — the same double-brace syntax used across the product — and you drop them into the URL or the request body. A variable like {{ticket.customer.email}} gets interpolated at send time with that ticket's actual data.

This means you have a genuine choice about payload weight. You can send a thin payload — just an ID — and let your service call back into the Gorgias API for the full object. Or you can send a fat payload with everything your downstream system needs, avoiding a round trip. A thin POST body on a ticket-created event might look like this:

{
  "event": "ticket-created",
  "ticket_id": {{ticket.id}},
  "customer_email": "{{ticket.customer.email}}",
  "channel": "{{ticket.channel}}",
  "subject": "{{ticket.subject}}"
}

Your endpoint receives that, and if it needs more, it authenticates back to Gorgias with HTTP Basic auth (your account email as the username, your API key as the password) against the base URL https://{your-domain}.gorgias.com/api/:

curl -u "[email protected]:YOUR_API_KEY" \
  "https://yourstore.gorgias.com/api/tickets/1234567"

Keep that callback pattern in mind for the limits section: Gorgias rate-limits the API, so a chatty "thin payload + call back for everything" design can bump into ceilings on a busy store.

Wiring an HTTP action into Rules

Beyond fixed event subscriptions, the more powerful pattern is triggering an HTTP call conditionally from Gorgias Rules. Rules are Gorgias's if-this-then-that automation engine, and one of the actions a Rule can perform is "make an HTTP request" using an integration you've defined.

That combination is what turns a raw webhook into something targeted. Instead of firing on every ticket-created event and filtering downstream, you let the Rule's conditions do the gating first:

1. Build the HTTP Integration under Settings (as above).
2. Create a Rule with conditions — e.g. channel is email and customer tag contains VIP.
3. Add the action Trigger HTTP integration and select your integration.
4. Set the Rule to run on ticket creation (or message created).

Now only VIP email tickets hit your endpoint. The events Gorgias can trigger on include Ticket created, Ticket updated, Ticket self unsnoozed, Ticket message created, and Ticket message failed — with a couple of the assignment/status events being mutually exclusive with the others, so check the toggles when you configure.

Retries, timeouts, and auto-disable

A webhook you can't trust is worse than no webhook, so it's worth knowing exactly how Gorgias behaves when your endpoint misbehaves. Per the HTTP Integrations docs:

Two practical takeaways. First, the 5-second timeout is strict — if your endpoint does slow work (a database write, a call to a slow 3PL), acknowledge the webhook fast with a 200 and process asynchronously, or you'll trip retries. Second, the auto-disable is forgiving by design: because the counter resets on any success, an endpoint that's mostly up won't slowly march toward being shut off. But an endpoint that's fully down for a stretch will hit 500 and go dark — and Gorgias won't loudly tell you, so monitor from your side.

The honest limits — and where an AI layer picks up

Gorgias's HTTP Integration is a solid, dependable primitive. It fires reliably, it retries sensibly, and the template-variable model gives you real control over payloads. Credit where it's due: for surfacing a customer's order history in the sidebar or notifying an internal system, it's exactly the right tool, and it pairs naturally with the customer sidebar to give agents context.

But notice what it is and isn't. A webhook is plumbing — it moves JSON from A to B. It does not read the customer's message, understand what they're asking, decide which of your systems to query, interpret the response, and write a reply. Every HTTP Integration still terminates at either a dumb sidebar widget an agent reads, or a downstream system that does its own narrow thing. The reasoning — "this is a where-is-my-order question, so call the 3PL, parse the tracking status, and phrase a helpful answer" — is not something a webhook does.

There are native limits too. HTTP Integrations don't expose agent/user lifecycle events (no agent-created or agent-deactivated webhook). The 5-second timeout rules out synchronous heavy lifting. And the API's rate limits are plan-tiered — API-key integrations get roughly 40 requests per 20-second window, with the ceiling rising on higher plans — so the thin-payload/call-back pattern has a real budget on a high-volume store, and much of Gorgias's richest data (revenue, order management, the built-in AI Agent) is gated behind Shopify connection and paid tiers.

This is the seam where an AI agent layer fits, and it's worth weighing the build-versus-buy tradeoff before you hand-roll a fleet of webhooks into custom services. The broader category of AI agents for customer service exists to do exactly the reasoning a webhook can't. Macha is one such layer: it runs on top of the Gorgias you already use as a native connector — it does not replace your help desk, your Rules, or your HTTP Integrations. Where a webhook hands off raw JSON, Macha is the smart consumer: it reads the ticket, calls your external systems through a custom tool that turns a REST endpoint into something an agent can invoke and reason over, then drafts or posts a grounded reply. Credits are consumed per AI action, not per resolution — see the pricing breakdown. The clean division of labor: keep Gorgias's HTTP Integrations as the reliable transport and system-of-record events, and layer an agent on top for the part the plumbing can't do — actually deciding and answering.

FAQ

Where are webhooks configured in Gorgias? Under Settings → Account → HTTP integration → Manage, then Add HTTP integration. Gorgias calls webhooks "HTTP Integrations," so there's no separate "Webhooks" menu item.

What events can a Gorgias webhook fire on? Ticket created, Ticket updated, Ticket self unsnoozed, Ticket message created, and Ticket message failed, among others. You can also trigger an HTTP request conditionally from a Rule so it only fires on tickets that match your conditions.

How does Gorgias handle webhook failures? Each request has a 5-second timeout and retries up to 3 times with exponential backoff (10s, 20s, then 40s). An integration auto-disables after 500 consecutive failures, and the counter resets after any successful request.

Can I control what data the webhook sends? Yes. You build the payload yourself using template variables like {{ticket.id}} and {{ticket.customer.email}} in the URL or request body — so you can send a thin ID-only payload and call back into the API, or a fuller object.

Can I add AI on top of Gorgias webhooks without replacing Gorgias? Yes. An AI agent layer like Macha connects to Gorgias as a native connector and acts as the smart consumer of your events and tools — reading tickets, calling APIs, and drafting or sending grounded replies — while Gorgias stays the system of record for tickets, Rules, and HTTP Integrations.

Ready to turn raw webhook events into real resolutions? Start a free trial of Macha and connect it to your Gorgias in minutes.