Shopify + Zendesk Integration

Often, yes. It is free, it shows the customer and their order history in the ticket sidebar, and if your agents only need to see orders while they type, install it and stop there. Custom work starts at three specific points: agents need to act on orders from the ticket, routing or SLAs need to key on order data, or several stores share one help desk. Install the native app first and only pay for whichever gap you actually have.

Not without additional scoped API work, and that work should be small and careful rather than large. We add an action app to the ticket sidebar backed by a service that holds a scoped Shopify Admin API token, enforces refund caps and permitted reasons, and ignores duplicate clicks. Every action is written to the ticket as an internal note, so finance has an audit trail to follow. Refunds created through the API cannot be deleted afterwards, which is why the guardrails are most of the project.

Because the match key is the requester email address, and people write to support from addresses they did not check out with. The order exists, the app is working, and the lookup still comes back empty. The practical fixes are an order-number lookup so agents can find any order regardless of the requester address, and recording alternate emails against the Shopify customer when support discovers them. Telling agents this during rollout prevents the "integration is broken" ticket to IT.

Not from the sidebar. Sidebar apps render in the agent browser, and triggers, automations, views, and SLA policies can only see ticket and user fields. If you want high-value orders answered first or repeat customers routed to a senior queue, order value and history have to be written into fields when the ticket is created, which takes a webhook-driven worker. This is the most common piece of custom work we build on Zendesk, and it is the difference between context agents can read and context the help desk can act on.

One help desk in front of several stores is where the questions get sharp: which store does this order belong to, what happens when the same email has bought from two stores, and should tickets route to store-specific groups or brands. We label every order and every synced field with its store, scope refund actions to the order actually on screen, and set routing per store, using Zendesk brands where your plan includes them. None of this is exotic, but it is design work, not a toggle.

We implement both, so the answer is not a pitch. Zendesk is the deeper support tool, and if your agents already live in it the right move is almost always to bring Shopify context into Zendesk rather than move the team. Service Hub makes sense when you already run HubSpot for marketing and CRM and want tickets beside the contact record with one bill. Switching help desks is disruptive out of proportion to the tooling gains, so the honest default is whichever one your team already answers tickets in.

On the Shopify side, no: the sidebar context and the custom actions work on any Shopify plan, because they use a scoped custom app rather than anything Plus-only. On the Zendesk side, the core build works broadly, but API rate limits and some platform features, such as brands for multi-store routing, vary by plan and edition. We check your specific plan against the scope during the audit rather than assuming, because a field-heavy backfill that fits comfortably on one plan can throttle on another.