Skip to content

Data requests

How a data request travels.

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.

Last measured Measured from the code, not reviewed by counsel Why this is not an agreement

Route

Three moves, and none of them is an e-mail to us.

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

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.

Two

You pass it on from Shopify admin

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

We act on it within 30 days

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

What each request does at our end.

Refik is subscribed to all three, each on its own endpoint with its own handler. The names are Shopify’s.

A data request — customers/data_request

We 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.

A shopper deletion — customers/redact

That 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.

A store deletion — shop/redact

Shopify 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.

Does a deletion reach the AI provider too?

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.

Can I see the three paths in more technical detail?

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

What comes back, and what does not.

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.

In the answer

  • Saved routines, with the date on each one
  • The first and last time that shopper was seen
  • How many conversation records exist for them
  • Back-in-stock requests still waiting, and the variants they were already told about
  • Any support handoff on file

Not in it

  • Not the conversation text itself — this path returns the count, and the conversations are in your own console
  • No name, phone number or address, because none is ever asked of Shopify or stored by us
  • Nothing belonging to another shopper, and nothing from another store

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

Three limits we will not paper over.

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 cannot be matched

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

Deleted rows stay restorable a while

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 preference profile is yours

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

What we keep on purpose, and what we cannot offer you.

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.

  • Our staff access log — 13 months

    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.

  • A denied attempt — 30 days

    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.

  • An address for everything else

    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.

  • One form, for messages only

    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.