Skip to content

Privacy

What we do with data.

Refik reads your catalogue and answers your shoppers, so it touches your data and theirs. This is the measured account: what is read, what is stored, what it is for, where it goes and how long it stays. The last section is what is still open.

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

Provider

Refik is a product of Pirahas Türkiye.

This is the company responsible for Refik and the one to write to about anything on this page. Which legal role it holds for each kind of data is a separate question, and it is on the open list at the bottom.

Company
Pirahas Türkiye
Address
Uludağ University ULUTEK Technopark, Bursa, Türkiye
Privacy and data contact
[email protected]

Responsibility

Your shoppers’ data is yours. Our own access log is ours.

Two different answers, and keeping them apart is the only way the rest of this page stays honest.

You hold the shopper relationship

  • The shopper is your customer and the data about them is your store’s
  • Refik processes it on your behalf, for the purposes below and no others
  • A shopper’s request goes to you, and Shopify carries it to us

That last one is not a deflection: we hold no contact route for a shopper, so a request sent to us directly could not be matched to anybody. The route that works is a page of its own.

The one record that is ours

  • Our staff access log: which of us opened which store or conversation, and when
  • It carries no IP address and no browser details — a work e-mail and a timestamp
  • It survives a store deletion for its security retention, because it is not the store’s record

It exists so that “nobody looked at your data” is a thing that can be checked rather than a thing we say.

That split is how the app is built, not a legal opinion about it. Which role each of us holds under a given law is one of the open questions at the bottom of this page, and it is on the list because a lawyer has not answered it yet.

From your store

What Refik reads out of Shopify.

Nothing here is collected by us; it is read through the permissions you approved, and the list of those permissions is the ceiling on all of it.

The ceiling

The permission list

Every scope Refik asks for is on Shopify’s own approval screen, and that screen is the whole of it. Adding one would put a fresh approval in front of every installed store, which is exactly why the list stays short.

Each scope, and what it is for

Orders

What an order answer uses

Order number and date, fulfillment status, expected and actual delivery, carrier name, tracking number and link, the carrier’s own event messages, and the product titles in the order. It opens for a shopper Shopify has proved, or for a guest who supplies an order number and the matching e-mail.

Measured absence

What is never asked for

No query anywhere in the server asks Shopify for a shopper’s first name, last name, phone number or address. The only place those words appear in the codebase is two instructions telling the assistant not to ask for them.

One thing is written back rather than read: the preferences a shopper states about themselves, saved to a metafield on their own Shopify customer record with a timestamp. It lives in your store, not in our database, and no other customer field is ever written.

Collected directly

What arrives through the chat, and what stays in the browser.

This is the half Shopify does not hand us. It is short, and the shortest item is the one people assume is the longest.

From a shopper

The conversation, and what they choose to type

Their messages and the assistant’s replies, a saved routine they build, and a thumbs up or down on an answer. Plus an e-mail address if they give one — to look up a guest order, to be told when something is back in stock, or to be contacted by your team.

A shopper can of course type anything into a chat box, including an address. When they do, it is in the conversation because they wrote it there.

In their own browser

A random identifier, held on their device

The storefront widget keeps a random identifier and the recent chat in the shopper’s own browser storage, so a guest’s saved routine survives a reload on that device. It contains no name and no contact detail.

This site — the one you are reading now — stores nothing at all, sets no cookie, and loads nothing from another domain. That is also why it never asked you to consent to anything.

For 60 seconds

An IP address, as a counter

One endpoint counts attempts per address, so a guest order lookup cannot be used to walk through sequential order numbers. The counter expires after 60 seconds and the address is never written anywhere else.

The bot check on our public demo sends a visitor’s address to Cloudflare for verification; the raw address is never written to our storage, and with that check unconfigured the free-form box is closed rather than left open.

Purpose

What it is used for, and what it is not.

Each row on the left is a feature you can see working. The right-hand list is the part that matters more, because you cannot see the absence of a thing.

Used for

  • Answering product, routine and policy questions out of your own catalogue and text
  • Order status and tracking, and opening a return request the shopper asked for
  • Handing a conversation to your team with the summary and a way to reply
  • A back-in-stock event sent to your own Klaviyo account, if you configured one
  • Remembering a stated preference and a saved routine for a returning shopper
  • Your console: conversation history, quality signals, and the count your plan uses
  • Security: the staff access log, the rate-limit counter, and error logs

Not used for

  • No sale of personal data, and no sharing of it for cross-context behavioral advertising
  • No advertising pixel, no cookie of ours on your storefront, no cross-site tracking
  • No marketing e-mail to your shoppers — the only e-mail we send goes to you
  • No model training. Neither AI provider’s terms permit training on what passes through
  • No decision with legal effect: a return is opened by Refik and approved by a person in your store

The training line is the one item on this page that is not a measurement of our code. It is read off two providers’ published terms, and it is on the open list at the bottom because those terms have to be read again on the day this becomes a policy.

Retention

How long it stays, and which half has no clock.

Two regimes, and the honest thing is to say which is which rather than average them into one comfortable number.

Kept for as long as Refik is installed

  • Conversation records: the shopper’s message and the reply, each capped in length, with the trace of which tools ran
  • Saved routines a shopper built
  • The first and last time we saw that shopper

That is a decision, not an oversight: it is how long they serve their purpose — recognizing a returning shopper, and letting you read back a conversation from last season. They go when you uninstall, or earlier if that shopper asks for deletion.

On a clock, taken from the code

  • Chat history used to continue a conversation, and the staff takeover queue — 7 days
  • Support handoff records, including the contact e-mail — 30 days
  • Conversation status, copies of staff messages, and reply feedback — 30 days
  • Usage counters — 90 days
  • Back-in-stock requests — until the notification is sent, or 180 days
  • Answers you write for questions Refik could not answer — 365 days from the last edit
  • Our staff access log — 13 months; a denied attempt, 30 days
  • The rate-limit counter holding an IP address — 60 seconds

Every period above is a constant in the code with a cleanup job behind it, not a number chosen for a policy. Two things sit outside both columns. Our hosting provider keeps a recovery window, so deleted rows may stay restorable there for up to 30 days — that is the provider’s mechanism and not a copy we keep on purpose. And the preference metafield lives in your Shopify customer record rather than our database, so while Refik is installed it is yours; we delete it on a redaction request.

Sub-processors

Who else touches it, and what their own terms say.

Four companies process data on our behalf. The list, with what each one does and what leaves our system to reach it, is on the security page rather than copied here.

The list, with purposes

  • Hosting, database, key-value storage, logs, and the bot check on our public demo
  • The AI model that writes replies and product summaries — today’s provider for every store
  • A second model provider that can do the same job; no store has been switched to it
  • Transactional e-mail for the console: your sign-in link, invitations, and alerts

Named, with the data that reaches each one, on the security page. A test walks every origin the code talks to and fails if one of them is missing from the policy, so the list is a measurement rather than a promise.

What happens at their end

  • Neither AI provider is permitted, under the terms we are on, to train on what we send
  • One provider’s terms describe deletion of inputs and outputs within 30 days, with an exception for content its own policies flag
  • The other keeps abuse-monitoring logs for up to 30 days, and no request setting of ours shortens that
  • A deletion at our end does not reach into either one’s logs

That last point is the one people are surprised by, so it is written here rather than left implied. Your Klaviyo account is not on this list at all: a back-in-stock event goes to your account under your own agreement with them, and only if you configured one.

Rights

Access, correction, deletion — and the route that reaches us.

Depending on where a shopper lives they may have the right to see their data, correct it, have it deleted, take it elsewhere, or object to how it is used. Because their relationship is with your store, the request starts there.

The route

Shopper, store, then us

Shopify forwards privacy requests to installed apps through three mandatory webhooks, and Refik is subscribed to all three and acts on them within 30 days. What each one returns or removes is a page of its own.

How a request travels

The limit

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.

The deletion paths

What each request removes

The three paths, and the one we cannot close, are set out with what they touch on the security page. This page says how long things stay; that one says how they go.

Deletion paths

The contact form

What this site collects when you write to us.

Everything above is about the app. The site has one form of its own, on the contact page, and this is all it does.

What is sent

  • Your name, your e-mail address, your store address if you give one, and your message
  • It is delivered as an e-mail to [email protected] by our hosting provider’s e-mail service, with your address set for the reply
  • It is used to answer you, and for nothing else; it is not added to a mailing list

What is not kept

  • The function that sends it has no database, so the site keeps no copy
  • Your IP address is not stored and is not in the e-mail; a one-way hash of it counts messages per minute, at the moment of sending
  • No cookie and no third-party challenge script; spam is filtered by a field a person never sees

The e-mail stays in the Pirahas inbox as correspondence. No deletion period has been set for that inbox, so none is written here.

Open

What is not settled.

This is the part a privacy policy usually leaves out, which is why a policy you cannot see the gaps in is worse than one you can. None of these carries a date.

  • A representative and a data protection officer

    The provider is named at the top of this page. Whether it also needs a representative in the EU or the UK, or a data protection officer, has not been decided, and none is named here.

  • A legal review

    Nothing on this page has been read by counsel. It is an accurate description of the code as far as we can measure; whether the description satisfies a given law is a separate question we have not put to anyone.

  • Which role each of us holds

    We treat you as the controller of your shoppers’ data and ourselves as the processor, and ourselves as responsible for our own staff log. That allocation is how the code is built, not a conclusion a lawyer reached.

  • Where the data physically sits

    Our hosting runs on a global network and we did not set a location preference for the database. Cloudflare placed it in eastern North America, and the server is configured to run in the US East region next to it. Neither is a region we have contracted for, so neither is a promise that it stays there.

  • What the hosting logs record

    Our own log lines are written by us and carry no shopper identifier we did not put there. Whether the platform’s request logs underneath contain an address or a browser string is not something we have verified, so it is not something we claim either way.

  • The basis for transfers

    Processing may happen outside the country you or your shopper is in, including in the United States. Our sub-processors’ own agreements incorporate the standard contractual clauses; whether that is the right mechanism for your store is a legal question, not a code one.

  • Children

    Refik is not built for children and nothing in it is aimed at them. The wording a particular law wants in a particular market has not been settled, so there is no age sentence here pretending to be one.

  • Browser storage and consent

    The storefront widget’s browser storage is not wired to Shopify’s customer-privacy consent signal today. Whether it has to be depends on which law applies to your store, and that is being decided before code is written for it rather than after.

Every one of those is written down because it is the kind of gap that closes quietly and then gets forgotten. The legal hub tracks the four that apply to all three pages; the rest belong to this one.