Gorgias Macro Variables Not Populating: Fixes

Symptom → likely cause, at a glance

Read what the reply actually rendered, then jump to the matching cause below.

The common causes, in order

1. The variable was typed by hand and has a small error

The single most common reason a variable renders literally — braces and all — is a typo in the path. Gorgias variables use a strict double-curly format, {{variable.path}}, and anything Gorgias doesn't recognize is left on the page verbatim. A single brace ({ticket.customer.firstname}), a stray space inside the braces, or firstName where the docs use firstname will all fail silently. Per the Gorgias macro variables documentation, the correct paths are lowercase throughout — {{ticket.customer.firstname}}, not a camel-cased or capitalized variant. Treat variable paths as case- and spelling-exact: match the documented path character for character.

The fix that avoids this entirely is the next cause.

2. It wasn't inserted through the variable picker

Rather than typing paths from memory, use the variable dropdowns at the bottom of the macro editor. When you're editing a macro, Gorgias shows selectors labeled by source — Ticket customer, Current agent, and one per connected ecommerce integration (Shopify, BigCommerce, Magento, and so on). Picking a variable from the correct dropdown inserts a validated chip into the body, so you can't misspell the path or drop a brace. If your hand-typed variable is coming out blank or literal, delete it and re-insert the same field from the picker instead. This is the surface the screenshot below shows.

3. There's simply no data for that variable on this ticket

If the syntax is perfect but the value still comes out empty, Gorgias is behaving exactly as designed. The documentation is explicit: "If the data isn't available for that ticket, the variable is replaced with a blank space." A {{ticket.customer.firstname}} that renders blank usually means the contact genuinely has no first name recorded; an order-number variable that's blank means no Shopify order is linked to that ticket. Open the ticket and check the customer sidebar on the right — if the panel isn't showing the order or profile you expect, the variable has nothing to read and will stay empty. This is why the same macro can work on one ticket and go blank on the next: the difference is the data on the ticket, not the macro.

4. Ecommerce variables need the store connected and the right order linked

Shopify, Recharge, and other ecommerce variables only resolve when that integration is connected and the ticket is matched to the right record. A common ecommerce trap: the customer emailed from a different address than they used at checkout, so Gorgias never linked the order, and every order-related variable in your WISMO macro comes back blank. Confirm the integration is live under Settings, then confirm the specific ticket has the order attached in the sidebar. Honest caveat: you can't fully exercise Shopify variables on a bare Gorgias trial — you need a connected store with real orders before these fields have anything to populate. For how macros and their variables fit together, see Gorgias macros explained.

5. Back-office (HTTP-integration) variables point at the wrong ID

Variables that pull from your own back office via an HTTP integration are the ones most likely to break, because their path contains a numeric ID you have to get exactly right. The format is {{ticket.customer.integrations[integration_id].data.field_name}} — for example {{ticket.customer.integrations[9141].data.delivery_cost}}. That 9141 is the integration's own ID, and per Gorgias you find it by opening the HTTP integration and copying the number from the end of the URL (e.g. 9141 from /app/integrations/http/9141). If you paste the wrong ID — or reuse a macro that was written against a different integration — the whole path resolves to nothing and the variable goes blank. Double-check that the ID in the macro matches the integration actually returning that field, and that the data.field_name segment matches the field name in the returned payload exactly.

6. The variable isn't in the picker at all

Some fields — particularly from certain third-party or WooCommerce-style integrations — can't be selected from the dropdown even when the integration is connected. In that case Gorgias' own guidance is that you can still type the variable manually between double curly braces, using the exact path. To find the correct path, open a ticket that already contains that back-office data and use the gear icon on the sidebar to view all available data fields; build your {{...}} path from what you see there rather than guessing. This is also the honest reason a variable can be "missing" from the picker but still valid — it's a manual-entry field, not a broken one.

How to actually test a macro before it reaches a customer

Gorgias doesn't ship a one-click "preview resolved values" button, so the reliable test is to run the macro against a real, fully-linked ticket rather than staring at the raw macro body. Open a ticket you know has the data — a real customer with a linked Shopify order — apply the macro to a draft reply, and read the rendered text before you hit send. If a variable comes out blank there, walk the checklist above: braces and spelling first (cause 1–2), then whether the ticket actually has that data (cause 3–4), then the integration ID for back-office fields (cause 5). Because the reply is still a draft, nothing goes out while you're debugging. To create or edit the macro you're testing, the path is Workflows → Tools → Macros, then click the macro name to open it and Save changes when you're done — as covered in the Gorgias macros documentation.

The honest limit of variables — and where an AI layer picks up

Macro variables are a genuinely useful shortcut, and none of the above is Gorgias' fault: a variable either has data to insert or it doesn't, and the blank space is the design telling you the data isn't there. That predictability is exactly why these failures are so diagnosable.

But it's also the ceiling. A variable can insert a value; it can't decide whether to. {{order.status}} will happily print "unfulfilled" whether or not that's the right thing to say to this particular customer at this particular moment, and it can't rephrase a WISMO reply, pick a different macro when the order is a pre-order, or apologize differently for a second late delivery. So teams end up maintaining a sprawl of near-duplicate macros — one per scenario — and those are precisely what quietly break when a field is renamed or an integration ID changes.

This is the seam where an AI agent layer helps. The broader category of AI agents for customer service exists to do the reasoning variables can't: read the order data, judge the situation, and write the reply — instead of stamping a fixed template with a value. Macha is one such layer, and it runs on top of the Gorgias you already use. It doesn't replace your help desk or compete with your macros; it connects to Gorgias, reads and writes the same tickets, and takes over the personalized, judgment-heavy replies your variable-driven macros were never built to handle — while your deterministic macros keep doing the simple, canned work they're good at. See the Macha–Gorgias integration and the practical walkthrough on how to connect Gorgias to Macha and automate ticket replies, or the Gorgias AI agent explained for the fuller picture.

Because an agent acts on meaning rather than a fixed path, you validate it differently: Macha lets you batch-grade a candidate agent against your real historical Gorgias tickets before it ever touches the live queue, and you can extend what it does with a custom tool that turns any REST API into an action the agent can call — looking up that same back-office order or delivery-cost field mid-conversation, without a hand-typed integrations[9141] path to maintain. Credits are charged per AI action, not per resolution; see pricing for the specifics.

FAQ

Why is my Gorgias macro variable showing as blank? Because there's no matching data for it on that ticket. Gorgias replaces a variable with a blank space when the data isn't available — so a blank first name means the contact has no first name recorded, and a blank order field usually means no order is linked to the ticket. Check the customer sidebar; if the order or profile isn't showing there, the variable has nothing to read.

Why is the variable printing literally with the {{ }} braces? That's a syntax problem, not a data problem. Gorgias prints anything it doesn't recognize as a variable verbatim, so a typo, a single brace, a stray space, or the wrong casing in the path will render literally. Delete the hand-typed variable and re-insert it from the Ticket customer or Current agent dropdown at the bottom of the macro editor so the path is guaranteed correct.

How do I use a back-office variable from my own system? Use the HTTP-integration path {{ticket.customer.integrations[integration_id].data.field_name}}, and get the integration_id from the end of that integration's URL (e.g. 9141 from /app/integrations/http/9141). If the exact ID or field name is off by anything, the variable resolves to blank.

Why isn't the variable I want in the dropdown? Some third-party fields can't be selected from the picker even when connected — those you type manually between double curly braces. Open a ticket that already has that data and use the sidebar's gear icon to see the available fields, then build the {{...}} path from what's shown there.

How do I test a macro without emailing a customer? Apply the macro to a draft reply on a real, fully-linked ticket and read the rendered text before sending. It stays a draft until you send it, so you can confirm every variable resolved — or spot which one went blank and walk the checklist.

Ready to stop babysitting WISMO macros and their variables? Start a free trial of Macha and let an AI layer read the order data and write the reply on top of your existing Gorgias workspace.