Shopify Zendesk integration for support teams

A Shopify Zendesk integration shows your support agents the customer's Shopify orders, fulfillment and tracking inside each Zendesk ticket, so they don't switch to the Shopify admin. Standard integrations from the Zendesk Marketplace do this well. A custom integration is worth building when agents need to take actions from the ticket, such as refunds, cancellations and address changes, with proper permissions, or when support needs data the standard app doesn't show: subscriptions, B2B accounts, warranty records or ERP delivery dates.

What agents need to see

• Customer: name, email, total orders, tags, notes, marketing consent.
• Orders: recent orders with line items, financial and fulfillment status, and discount codes.
• Fulfillment and tracking: carrier, tracking number and link, delivery status, and which items are still unfulfilled.
• Returns and refunds already processed.
• Context from other systems: subscription status, B2B company and payment terms, warranty or serial numbers, ERP delivery estimates.

What agents want to do

• Refund all or part of an order, with or without restocking.
• Cancel an unfulfilled order.
• Update the shipping address before fulfillment.
• Resend the order confirmation or shipping notification.
• Create a replacement or exchange order.
• Add a note or tag to the order or customer.

Off-the-shelf options

• Shopify integrations in the Zendesk Marketplace, including Zendesk's own, which show order data in the ticket sidebar.
• Helpdesk-agnostic Shopify support apps that add actions such as refunds and edits.
• Middleware for creating tickets from Shopify events.

Where the standard integration stops

• Actions with guardrails. Refunds above a threshold need approval. Some agents can cancel but not refund.
• Custom data. Subscriptions, B2B, metafields and data from your ERP or warehouse system.
• Matching. Customers writing from another address, or several accounts with one email.
• Proactive tickets from Shopify events.
• Audit. Knowing which agent refunded what, and why, in both systems.

How a custom Shopify Zendesk integration works

1. A Zendesk sidebar app built with Zendesk's Apps framework. It runs in the ticket view and calls your backend, never Shopify directly, so no Shopify credentials sit in the browser.
2. Your backend is a Shopify app installed on the store. It authenticates the request from Zendesk, looks up the customer by email or order number with the GraphQL Admin API, and returns a compact view of orders, fulfillments and custom data from metafields or other systems.
3. Actions go through the same backend. A refund calls refundCreate after showing the agent a preview. Cancellations, address updates and notes use their own mutations. Each action checks the agent's role and limits, and is logged with the agent ID and ticket ID, including as a note on the Shopify order.
4. Shopify → Zendesk: webhooks such as fulfillments/update, orders/cancelled and refunds/create update the matching ticket, or create a new one for events that need attention.
5. Privacy: the sidebar shows only what agents need, and your backend enforces the same data minimisation as any app accessing protected customer data.

Worked example: a "where is my order?" ticket

This is the most common support request for most stores, and a good test of any integration:

1. A customer emails from jane@example.com: "Still waiting for order 1042."
2. The sidebar app sends the requester email and the ticket text to your backend. The backend finds the order number in the text, looks up order #1042 through the GraphQL Admin API, and checks that the order's customer email matches the requester. If it doesn't match, the agent sees a warning instead of order details.
3. The agent sees the order, its fulfillment orders and the tracking number, with the carrier's latest status if you also integrate a tracking provider.
4. A macro inserts the tracking link into the reply. If the parcel is lost, the agent clicks Create replacement. The backend creates a new order at zero cost, tags both orders and writes a note linking the ticket.
5. When the replacement ships, the fulfillments/create webhook adds an internal note to the ticket with the new tracking number, so the next agent has the full story.

Every step uses supported APIs, and nothing needs the agent to open the Shopify admin.

Several stores, one helpdesk

Merchants with a store per region or a separate wholesale store often run one Zendesk account for all of them. The backend then:

• holds a token for each store (the same custom app installed on each);
• searches all stores by email and shows results grouped by store;
• routes actions to the store the order belongs to;
• labels every order clearly with its store and currency, so agents don't refund in the wrong one.

Failure modes to design for

• Rate limits. A busy Monday with dozens of agents opening tickets means many Admin API calls. Cache recent lookups for a short time and request only the fields the sidebar shows.
• Stale data. A cached order may have been refunded a minute ago. Always re-fetch before taking an action, and show when the data was loaded.
• Partial failures. A refund succeeds in Shopify but the ticket note fails. Log the action first, then update the ticket, and retry the note.
• Permission drift. When agents change roles in Zendesk, the backend must check the current role on each action, not the one at sign-in.
• Customer identity. Never reveal an order to a requester whose email doesn't match, unless the agent explicitly overrides after verifying the customer.

Decision checklist

• Which actions should agents take from Zendesk, and which roles may take them?
• What data outside Shopify does support need to see?
• How do customers usually identify themselves: email, order number or phone?
• Which Shopify events should open or update tickets?
• Who needs the audit trail: finance, support leads, or both?