One
The shopper asks the store
Their relationship is with you, and the data about them is your store’s. We hold no contact route for a shopper, so a request sent to us would arrive with nothing to match it against.
Data requests
A shopper who wants their data, or wants it gone, sends the request to the store they shopped with — not to us. Shopify carries it the rest of the way, through three webhooks every app has to answer. This is what happens at our end of each one.
Route
The route reads like an extra step, and it is the opposite: it is the only path where the request arrives attached to a shopper we can actually find.
One
Their relationship is with you, and the data about them is your store’s. We hold no contact route for a shopper, so a request sent to us would arrive with nothing to match it against.
Two
Shopify has a request and an erase action on a customer record. Using it notifies every installed app, Refik included, with a signed request naming that customer.
Three
Signature first, then the body: the raw text is read to check the signature and only parsed afterwards. Which store the request belongs to is taken from the signed body and never from an unsigned header.
That last detail is not decoration. If the store were read from a header instead, one shopper’s deletion request could be pointed at another store’s rows — so the field that decides whose data is touched is inside the part Shopify signed.
The three
Refik is subscribed to all three, each on its own endpoint with its own handler. The names are Shopify’s.
customers/data_requestWe assemble what we hold for that shopper so you can answer them: their saved routines and the dates on them, the first and last time we saw them, how many conversation records exist, any back-in-stock requests still waiting and the variants they were already told about, and any support handoff on file.
Counts and dates, assembled for you to pass on. The record that we answered is itself kept only until that shopper’s data is deleted or you uninstall.
customers/redactThat shopper’s saved routines, the first and last seen record, all of their conversation records, the record of any earlier data request, their back-in-stock requests and the markers saying they were already notified, their own support handoff, and the preference metafield on their Shopify customer record.
Where one chat session was used by two people — a shared device, a shop tablet — those few shared rows are left alone. Deleting too little beats deleting somebody else’s data.
shop/redactShopify sends this one forty-eight hours after you remove the app. Every database row for your store goes, and so do the key-value records and the knowledge base built from your catalogue. Our own staff access log stays for its security retention, because it is our record rather than yours.
If the deletion cannot finish inside one request it is queued and retried, and the request keeps reporting an error until it completes — so Shopify sends it again rather than the work being quietly skipped.
No, and this is the answer people are most often surprised by. The conversation was sent to the model at the moment it happened; a deletion here removes our copy and does not reach into a provider’s own logs. How long a copy stays on their side is set by their terms, not by us.
What those terms say today — including the one retention no request setting of ours can shorten — is on the privacy page.
Yes. The security page has the same three with the row names they touch, what uninstalling does immediately, and the limit we cannot close. This page is the procedure; that one is the mechanism.
The answer
A data request is answered with a record of what exists, not with a dump of everything that ever passed through. That is a limit worth saying out loud rather than discovering.
If what a shopper needs is the conversation itself rather than a record that one existed, it is in your console and it is yours to send them. We are not the bottleneck there.
Limits
Each of these makes deletion less complete than the sentence “we delete it” suggests, so each one is written down instead.
The one we cannot close
A guest shopper is only a random identifier in their own browser. We hold no contact details for one, so an e-mail request cannot be matched to those records. They go when you uninstall, and there is no shorter route.
We would rather write that down than describe a deletion path that does not exist.
The provider’s window
Our hosting provider keeps a recovery window, so rows deleted from the database may remain restorable there for up to 30 days. It is the platform’s mechanism rather than a copy we keep, and it is the reason deletion is not instantaneous everywhere.
It is in your store
The preferences a shopper states about themselves are saved to a metafield on their Shopify customer record, not to our database. We delete it on a deletion request; while Refik is installed it is your record and you can see it in Shopify.
Our side
Two of these are a decision. The other two are gaps, and they are on this page because a procedure with an invisible gap is not a procedure.
It records which of us opened which store or conversation, and when. It is our record rather than yours or a shopper’s, so a store deletion does not remove it, and an investigation reaches back further than a month. It holds no IP address and no browser details.
An access attempt that was refused is kept a month: long enough to notice a pattern and look into it, short enough that a failed probe does not sit in the table for a year.
A merchant, or anyone with a question about this page, can write to Pirahas Türkiye at [email protected] or through the contact page. A shopper’s request still belongs with the store, because nothing we hold would let us match it to them.
The contact page carries the only form on this site. It sends an e-mail and stores nothing, so it is a way to ask a question rather than a way to file a deletion: a deletion runs through the route at the top of this page, which needs neither an address nor a form.
The legal hub tracks the four things still missing from every legal page here. Something on this page unclear, or contradicted by what you see in your own Shopify admin? That is a bug in the page, and the page is the thing we would fix.