Skip to content

Integrations · Shopify

One install, and the edges it is held inside.

Shopify is not one of the things Refik connects to. It is the floor: the admin screens, the storefront surfaces, the identity of a request and the list of what may be read all come from Shopify, and Refik has no second platform to fall back on. That makes the honest version of this page a description of edges rather than of features — what Shopify hands over, what it refuses to hand over, and which parts of your store Refik is written never to touch.

Status Working today Webhook API version Back to the full list

Where it lives

Two places, and neither of them is a dashboard of ours.

There is no Refik website you log into. The app is declared embedded, which means its screens are rendered inside your Shopify admin and your Shopify session is the only session involved. The storefront half is a theme app extension — a separate thing from the admin half, with its own on and off switches that live in Shopify’s theme editor rather than in anything of ours.

Admin

Screens inside your admin

Setup and the console are pages in your Shopify admin. Nothing asks you to create a password with us, and there is no second account to lose: the app is embedded, so who you are is whoever Shopify says you are on that request.

The install itself uses Shopify’s managed flow rather than the older redirect dance — the legacy install flow is switched off in the app configuration, so there is no consent screen of our own design in the middle.

Storefront

Blocks in your theme editor

The shopper-facing surfaces are theme blocks. You add them where you want them and remove them the same way, and there are five of them rather than one monolithic widget, so a store can run the question bar without the chat bubble, or the routine suggestion on its own.

Every block carries its own copy in eleven storefront languages, picked from the locale your theme is already serving.

What stays untouched

Your theme files are not edited, and that is a design decision with a cost.

A theme app extension ships its own files. Refik never writes into theme.liquid or any other template you own, which is why updating your theme does not break the assistant and uninstalling does not leave fragments behind for you to find later. The cost is honest and worth stating: because nothing is injected, a block only appears where you place it, and a store that installs the app and never opens the theme editor gets admin screens and no storefront at all.

No template is rewritten, so no template can be left broken

The extension is declared as a theme extension and its blocks live in its own directory. Apps that edit theme files have to put their changes back when they leave, and the interesting failure is not the edit — it is the removal that half-succeeds a year later against a theme that has since been replaced.

The same decision explains why there is no “install and it appears everywhere” option. Placement is a choice you make in a tool you already know, and it is reversible without us.

Each surface is switched independently

Blocks are separate entries in the theme editor rather than settings inside one block. A store that wants help only on product pages can have exactly that, and switching a surface off is a theme change rather than a support request.

This is also the honest limit on anything this site says about “what Refik does”: the answer depends on which blocks you turned on, and we cannot see your theme from here.

Checkout, pricing and fulfilment are outside the line

Refik answers questions. It does not alter a price, apply a discount, edit an order or touch fulfilment, and the access it asks for reflects that — the read side is the catalogue, inventory, orders and your own published policies.

The full list of scopes, including the two that write rather than read and what each one is for, is on the security page instead of being restated here.

The access scopes, one by one

How a request is proved

A shopper request arrives on your own domain, and it is checked before it is answered.

Shopper traffic does not go to a third-party domain. It goes through Shopify’s app proxy, which means the request is made to a path under your own storefront and Shopify forwards it to Refik with a signature attached. Refik recomputes that signature from the parameters it received and compares the result; a request with no signature is refused rather than answered on the assumption that it is probably fine.

What the check actually covers

The signed text is built from every forwarded parameter except the signature itself, sorted so that the order a browser happened to use cannot change the result. That is the part worth knowing: the check proves the request came through Shopify for a given store, so the store a request belongs to is read from the proxy parameters rather than from anything a caller can simply claim.

What it does not cover

It does not prove who the shopper is, and Refik does not pretend otherwise — the logged-in customer identifier is one of the forwarded parameters, so it is only as trustworthy as the proxy itself. It also says nothing about whether the question is a reasonable one; that is the assistant’s problem, not the signature’s.

Interface illustration, drawn from this page’s own account of the proxy check — the request is made to a path on your own storefront, Shopify forwards it with a signature attached, and Refik rebuilds that signature from the parameters it received, sorted and with the signature itself left out. The dashed box is the page’s own refusal case: a request carrying no signature is refused rather than answered on the assumption that it is probably fine. The two lines below are the division the section already makes between what the check proves and what it does not. No number here is a measured figure.

What Shopify tells us

Shopify also talks back, on five separate routes.

Notifications arrive as webhooks, and each subject has its own route rather than one catch-all endpoint that then has to guess what it received. Three of them are the data-request and deletion notices every Shopify app is required to accept; the fourth is the app being uninstalled; the fifth is a product changing, which has its own page because the interesting part is what happens after the notice arrives.

Required

Data request

A shopper asks what you hold about them, forwarded by Shopify.

Required

Customer deletion

A named shopper has to be removed, and the deletion paths are written down.

Required

Shop deletion

A whole store leaves and everything belonging to it goes with it.

Lifecycle

Uninstalled

The app is removed; the record of that store stops being used.

The deletion routes are described, with what each one removes and how long it takes, on the security page and in the data requests document. Product changes get their own page because the webhook is only the first half of the story.

How a catalogue change reaches a shopper

The limits of this page

Shopify being the floor is also the risk.

There is no second platform. If your store is not on Shopify, Refik has nothing to read and nothing to render, and no amount of configuration changes that. Within Shopify there are further edges: the assistant answers from what the platform exposes, so a fact you keep only in a spreadsheet or only in a photograph is a fact it does not have. And the two halves can be installed without each other — the admin screens working tells you nothing about whether a shopper can see anything, because that depends on blocks you place yourself.

Nothing on this page is a claim about uptime, about a certification we do not hold, or about how fast a change propagates. The propagation question has a measured answer and it is on the next page rather than estimated here.