Legal

Privacy Policy

Last updated: 10 November 2026

How GiftingStack handles personal data: for the developers who use our API, and for the end users of the apps they build.

1. Who we are

GiftingStack ("we", "us") provides an API that lets apps add virtual gifts between their users: balances, a gift catalog, gift sends and a ledger. GiftingStack is operated by an individual developer based in the Republic of Türkiye, who is the data controller. Their identity and postal address are available on request. Contact: support@giftingstack.com.

2. Two groups of people

Customers are the developers and companies that sign up and use the API. For their account data we are the controller.

End users are the people who use a customer's app. We process their data only on the customer's behalf, as a processor, under the Data Processing Addendum. The customer decides why and how that data is used. If you are an end user and have a question or request about your data, please contact the app you use. We will help that app answer you.

3. What we process

Customer account data

• Your email address (to sign you in).
• Your projects, settings, gifts, webhook endpoint URLs and signing secrets (secrets stored encrypted) and API key prefixes. API keys and sign-in tokens are stored only as hashes.
• Images you upload in the dashboard for your gifts (PNG, JPEG or WebP). They are stored with Cloudflare (R2), in the location Cloudflare chooses automatically (see section 7), and served from uploads.giftingstack.com, a domain that sets no cookies. We store the image with its size, type, dimensions and upload date, not the file name. We keep an image until you delete it or the project is deleted; after a project deletion it is removed within the deletion period described in section 5. An uploaded image is public: anyone who has its address can open it.
• Sign-in and session records (a session lasts 14 days), and a record of account actions such as creating or revoking a key, changing a plan or suspending a project. These audit records are kept while the project exists.
• Which version of the Terms of Service you accepted and when: the sign-in form says that continuing means agreeing to the Terms and confirming you have read this policy, and we record the version (the newest "Last updated" date of the Terms, this policy and the DPA) with the time of the sign-in. It is kept with your account record.
• Team members and invitations: the email addresses of people you invite, their role, and the invitation email we send on your behalf.
• If you use receipt verification or store notifications: the store credentials you give us (the bundle ids for Apple, a Google service account key for Google), stored encrypted.
• Notes we keep ourselves: the owner of GiftingStack may add a short internal note about a project (for example about support or a plan) and, when a live environment is suspended, the reason. The reason is shown to you; the note is not. We use them to run and protect the service.
• Billing details for paid plans. Payments go through Creem as merchant of record. We do not receive or store card numbers.
• Messages you send us.

End-user data held for customers

• An identifier chosen by the customer (external_id). We reject identifiers that contain an "@" so email addresses are not used by mistake.
• Balance and ledger entries: amounts, reasons and the customer's own references.
• Gifts sent and received, and the optional short message (up to 280 characters) and metadata the customer's app attaches.
• Webhook event records for 30 days, so customers can catch up on missed events.
• An optional display name the customer puts in a client token, used as the sender's name in gift rooms.
• Counters derived from gifts: leaderboard totals per period, gift wall counts and which gifts a user has already seen in a "while you were away" summary.
• Sale records on credits: a credit may carry a price and currency (declared by the customer for a web sale, or taken from a verified store receipt). We use them to calculate the service fee and to check it (see the Terms). They add nothing about the end user beyond the credit itself, but because a credit belongs to a user identifier they can still be personal data. For calculating, checking and collecting our own fee we decide how these records are used, so for that purpose we are a controller, not the customer's processor.
• Store purchase records, when the customer uses receipt verification or store notifications: purchase receipts the customer's server submits to us for checking, and the notification payloads Apple (App Store Server Notifications) or Google (Play Real-time Developer Notifications) send to us on the customer's instructions. They contain the store's transaction and order ids, product ids, prices and currencies, purchase, renewal and refund dates, the type of each notification, and a hash of the customer's user identifier when the customer sends one with a receipt. They contain no card or bank details and no names or email addresses. We use them to confirm a purchase is real and unused, to report refunds to the customer and, on the live environment, to calculate our service fee: a credit with a verified receipt is a store sale priced by the store, and a store refund reduces the fee base. For Google Play we read the order's price with the customer's own service account. To convert prices to US dollars we use the European Central Bank's public daily reference rates, which contain no personal data. The money always goes from the store to the customer, never through us.

What other users of the customer's app can see

When a customer's app uses these features, some end-user data is shown to other users of that app:

• Gift rooms: everyone in the room receives each gift sent into it: the gift, the quantity, the sender's user identifier and display name, the receiver's user identifier and the time. Rooms keep gift events in memory for about 15 seconds so a reconnecting viewer can catch up. While a battle round is open, the room also stores the round: the receivers' user identifiers, their scores and the ids of the gifts counted. A room erases everything it stores about 6 hours after its last viewer left and its round ended.
• Leaderboards: user identifiers with their gift counts and ranks.
• Gift walls: the gifts a user or a post received, with counts.
• "While you were away": shown only to the user it is about: the gifts they received while away, and who sent them.

Balances, gift messages and metadata are never shown through these features; while a battle round is open, its scores (totals per receiver) are. The customer decides which of them its app uses and which names it sends, is responsible for moderating display names and messages, and must tell its users about it.

Operational data

• Service metrics (Cloudflare Workers Analytics Engine): for each API or room request we record counts and timings: the route pattern (never the concrete path), HTTP method, status class, latency, outcome codes, plan name and the project id. They contain no gift messages, metadata, external_id, user identifiers, room identifiers, IP addresses or keys. Cloudflare keeps them for about 3 months.
• Logs: our own log lines carry only fixed codes and counts. We have switched off Cloudflare's automatic request logging for the API and rooms Workers, because request addresses can contain end-user and room identifiers.
• Rate limiting uses Cloudflare rate-limiting counters keyed by IP address or API key; we do not store IP addresses in our databases.

What we do not collect

No payment card or bank details of end users, no identity documents, no location data, no audio, video or chat. GiftingStack does not handle real money.

4. Why we process it and on what basis

• To run the service you asked for (account, sign-in, API, dashboard): performance of a contract.
• To keep it secure and prevent abuse (rate limiting, bot checks, audit records, suspending a project, service metrics): our legitimate interest.
• To meet legal obligations, such as tax and accounting records for paid plans.
• End-user data: on the customer's documented instructions.

5. How long we keep it

• Sign-in links expire after 15 minutes and can be used once.
• Idempotency records are kept for 24 hours.
• Webhook event records are kept for 30 days. The delivery log (the status of each attempt to reach a customer endpoint) is kept for 90 days, so a customer can show when its endpoint was told. A webhook that cannot be delivered is retried for up to 5 days and waits in a queue meanwhile.
• Refused requests (a credit, debit, gift or reversal the API turned down) are kept for 180 days, so a customer can show what was asked and why it was refused: the error, the time, the amount, the reference and the user's balance at that moment, never the gift message or metadata.
• Gift room data: a room erases everything it stores about 6 hours after its last viewer left and its battle round ended.
• Sessions expire after 14 days.
• Sale records on credits are kept while the project exists, as the record behind the service fee. Store purchase records (verified receipts and notifications, which the service fee is calculated from on the live environment) are kept while the project exists; the log of store notifications is kept for 30 days.
• Ledger entries are kept while the project exists. They are an accounting record and are never edited. Account audit records and the owner's internal notes are kept while the project exists too.
• Project deletion: the owner of a project asks for it in the dashboard. The API keys of both environments stop working immediately. For 7 days the owner can cancel. After that, a daily job permanently erases the project's data from live systems (both ledgers with all end users, balances, gifts and events, the catalog, keys, webhooks and delivery log, uploaded images, team, store records and the project's audit records). This normally completes within about 8 days of the request.
• When a customer deletes an end user through the API, that user's identifier is replaced with a random one, messages and metadata are erased, and the balance is closed with a ledger entry. Store purchases verified for that user lose the keyed hash that linked them to the identifier. Amounts and dates remain under the new random identifier. We keep no record of the old identifier, but this is pseudonymisation, not anonymisation: whoever still holds the old identifier elsewhere (for example the customer) may be able to link the records again, so we keep treating them as personal data.
• Account deletion: you can delete your account in the dashboard once you no longer own a project (delete or transfer the projects first). We then erase your account record, sessions, sign-in links, memberships, invitations sent to you and your own audit records. Where you appear in another customer's project records, you remain only as an anonymous "deleted account".
• What deletion does not remove at once:
  • Cloudflare backups and point-in-time recovery: up to 30 days (for one database product 7 days, depending on our Cloudflare plan). We do not restore deleted projects from them. So data can remain until about 38 days after a project deletion request.
  • Webhook messages already waiting in a queue for retry (up to 5 days). They are sent nowhere once the project's endpoints are gone and expire on their own.
  • When a gift receiver is deleted through the API, the sender's refund entry keeps its metadata: it is the sender's record.
  • Cloudflare's own short-lived logs and service metrics (a few days to about 3 months, containing no end-user data), and the records our email provider and payment provider keep under their own rules.
  • Copies the customer holds itself: webhook events already delivered, its own database, exports.
  • Records we must keep by law, such as invoices, kept for the legal period.

6. Who we share it with

We use a small number of service providers (sub-processors):

• Cloudflare: hosting, networking and data storage for the API, dashboard and website.
• Resend: sending sign-in and team-invitation emails to customers.

Creem is the merchant of record for paid plans and receives the billing details you enter at checkout. Apple and Google are sources of purchase data a customer chooses to send us, not our sub-processors. Cloudflare's services we use include Workers, Durable Objects, D1, R2, Queues, Analytics Engine, Turnstile and Email Routing (messages you send to our support address are forwarded to the owner's mailbox).

We do not sell personal data and we do not use it for advertising. We may disclose data if the law requires it.

7. Where data is stored

Cloudflare runs a global network. When a customer creates a project they can choose a region (US East, US West, EU or Asia-Pacific). This tells our storage where to place the project's data. It is a placement preference, not a guarantee that data is never processed elsewhere. Account data (accounts, keys, sign-in) is held in one database in Western Europe. Where personal data is transferred outside the EEA or the UK to our providers, we rely on the safeguards they offer, such as standard contractual clauses. GiftingStack itself is operated from the Republic of Türkiye and has no signed transfer mechanism of its own (such as standard contractual clauses) in place today; if you need one, write to us.

8. Cookies and similar technologies

This website sets no cookies of its own and uses no analytics or advertising trackers. It stores only the platform tab you select in the docs (key gs-platform) in your browser's local storage, which never leaves your browser. Its fonts and images are served by us. The dashboard sign-in page loads Cloudflare Turnstile (from challenges.cloudflare.com), a bot check that receives your IP address and browser signals and may store its own data in your browser; we do not use it for tracking. The dashboard sets two cookies. __Host-gs_session keeps you signed in for up to 14 days. __Host-gs_login binds a sign-in link to the browser that asked for it and lasts up to 30 days. Both are strictly necessary, HttpOnly, Secure, SameSite=Strict and not used for tracking. The dashboard also remembers, in your browser's local storage, the page you were heading to while accepting an invitation.

9. Security

Data is encrypted in transit. API keys, session tokens and sign-in tokens are stored as hashes. Each project and environment (test or live) is stored separately. Our own logs and metrics do not contain gift messages, metadata, end-user identifiers, display names or room identifiers. IP addresses are used to limit abuse and are not stored in our databases. Access to production data is limited to the owner of GiftingStack, who can technically read project data when needed to run or support the service. Sign-in is by emailed link (no second factor). See the DPA for more.

10. Your rights

Depending on where you live, you can ask for access to your data, correction, deletion, restriction, objection and a portable copy, and you can withdraw consent where we rely on it. This includes the rights under the Turkish Personal Data Protection Law (KVKK). Write to support@giftingstack.com. You can also complain to your data protection authority.

If you are an end user of a customer's app, write to that app first, because it decides how your data is used. If your request reaches us, we pass it to the customer or help the customer answer it.

11. Children

GiftingStack is a service for developers and is not directed at children. Customers are responsible for how their own apps treat children's data.

12. Changes

If we change this policy in a meaningful way we will update the date above and tell customers by email or in the dashboard.