Data Processing Addendum (DPA)

This addendum ("the Addendum") is an integral part of the Terms & Conditions and applies automatically to every merchant using the Capi Agent platform ("the Platform", "we"). It needs no separate signature: by accepting the Terms you accept this Addendum.

When we process your customers' data — conversations, phone numbers, email addresses, social-media handles, orders, carts, tags, notes, and consent state — you are the Controller (Controller under the GDPR, "controlling entity" under the Saudi PDPL, veri sorumlusu under the KVKK) and we are the Processor (Processor / veri işleyen). This Addendum is written to satisfy Article 28 of the EU GDPR, the processing-entity requirements of the Saudi Personal Data Protection Law (PDPL), and the data-processor obligations of the Turkish KVKK.

Your own account and team data (names, email, billing, dashboard usage) we process as a controller; it is covered by the Privacy Policy, not by this Addendum.

• Customer Data: all personal data relating to your store's customers, prospects, or team members that we process on your behalf through the Platform.
• Documented Instructions: the Terms, this Addendum, and the settings you choose yourself in the dashboard.
• Subprocessor: any provider we engage to process Customer Data on your behalf.
• Data Breach: any security incident leading to the destruction, loss, alteration, disclosure of, or unauthorised access to Customer Data.
• Applicable Law: the EU GDPR, the Saudi Personal Data Protection Law (PDPL), the Turkish Personal Data Protection Law (KVKK), and any mandatory data-protection law that applies to you.
• Any other term (controller, processor, data subject, processing) has the meaning given to it by Applicable Law.

We process Customer Data only on your Documented Instructions: the Terms, this Addendum, and the settings you configure yourself in the dashboard — the channels you connect, the agent's autonomy level, caps and tools (/dashboard/ai-agent), the conversation retention window (/dashboard/settings/data-rights), and your campaign and automation rules. Every change you make to those settings counts as a new documented instruction. Turning on ad data sharing (/dashboard/ads) is such an instruction: it directs us to send Meta a purchase event for orders that came from a Click-to-WhatsApp ad, limited to the click id Meta issued, the event name, the order's value, currency and id, and the time — and it is off until you turn it on. The Snap switch on the same page is the same kind of instruction, with Snap's click id and the landing page URL in place of Meta's click id — and so are the TikTok and Google Ads switches, each with that platform's click id; the Google grant you give through your own Google sign-in is part of that instruction. The same switches also cover (since 08.10.2026) the purchase event when the order itself carries the platform's click id, shopping events (product viewed, added to cart, checkout started) for a visitor who came from that platform's ad, and the «lead» and «order cancelled» events for WhatsApp conversations from a Meta ad. Turning on «enhanced matching» (/dashboard/ads/tracking) is a separate instruction, recorded in your name: it directs us to add the buyer's email, phone, name, city, country, postcode and our customer id, hashed with SHA-256, together with the order's IP address unhashed, to the purchase events sent to the platforms you share data with — only to credit the sale to its ad. It is off until you turn it on, and turning it off stops it at once. By turning it on you confirm you have a lawful basis for this sharing and have told your customers about it in your store's privacy policy. Turning on audiences for a platform (/dashboard/ads/audiences) is a separate instruction: it directs us to upload the phone numbers and emails of your consenting, non-blocked customers, hashed with SHA-256, as a customer list in your own ad account, and to remove them there when consent is withdrawn, a customer is blocked, or the switch is turned off. Launching, pausing, changing the budget of or stopping a campaign from Capi is an instruction for that campaign only. Asking Capi to suggest TikTok search keywords is an instruction to have an AI model read your customers' messages — customer side only, phone numbers and emails masked — for that suggestion only.

We do not process Customer Data for any purpose of our own: we do not sell it, we do not use it for advertising, and we do not train AI models on it. One merchant's data never influences another merchant's agent.

If we believe an instruction of yours infringes Applicable Law, we will tell you immediately and may suspend carrying it out until it is clarified. If a law requires us to process the data differently from your instructions, we will inform you beforehand unless that law itself prohibits doing so.

Our staff can access your customers' data in only two situations: a support request from you, or the investigation of a security incident. Access is limited to the least privilege necessary, and every sensitive operation is written to an audit log retained for 365 days.

Everyone working with us who can access Customer Data is bound by a written confidentiality obligation that survives the end of their engagement.

Encrypted values (API keys, platform and channel tokens, two-factor secrets) are never written to any log and never sent to the browser.

We apply appropriate technical and organisational measures to protect Customer Data, detailed in Annex 2 below and on the Security page. The main ones:

• Encryption in transit (TLS/HTTPS with HSTS) and encryption of every secret column at rest with AES-256-GCM.
• Full tenant isolation: every query is scoped to the organisation and store, and authorisation is verified on the server, never taken from the browser.
• Signature verification of every webhook (HMAC-SHA256) and of job-queue messages, plus rate limiting that never fails open.
• A nightly database backup retained for 7 days.

We may update these measures as threats evolve, provided the overall level of protection is not reduced. We do not claim any external certification (such as SOC 2 or ISO) at this stage.

You give us a general authorisation to engage subprocessors. The current list — with each provider's purpose, the data it receives, and its location — is published on the Subprocessors page and covers hosting (Vercel), the database (Neon), storage (Cloudflare R2), queues and cache (Upstash), model providers (Anthropic, OpenAI, or Google, per your choice), channels (Meta, X, Resend), payments (iyzico), and error monitoring (Sentry).

We bind every subprocessor to data-protection obligations no less protective than those in this Addendum, and we remain responsible to you for its performance.

Before any material addition of a subprocessor we notify you by email to the account owner's address and by an in-dashboard notice before it takes effect. If you have a reasoned objection on data-protection grounds, tell us; if we cannot offer a reasonable alternative, you may terminate your subscription before the change takes effect, without any penalty.

Your store's customers address their requests (access, correction, deletion, objection, portability, withdrawal of consent) to you as the Controller. The dashboard gives you the tools to handle most of them yourself: delete, correct, or export any customer from the Customers page (/dashboard/customers), and a consent log that records when, on which channel, and with which text a customer opted in or out.

If you need our help with a request you cannot complete from the dashboard, email privacy@capiagent.com and we will assist you within 30 days at most.

If a request reaches us directly from one of your customers, we do not answer it on your behalf; we forward it to you without delay and tell the requester that your store is the party responsible for responding.

If we confirm a Data Breach affecting your customers' data, we notify you without undue delay and no later than 72 hours after confirming it, at the account email and by an in-dashboard notice.

The notice includes, as far as the information is available at the time: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures we have taken or propose to limit the harm, and a contact point on our side. If not all information is ready, we send it in stages without waiting for it to be complete.

Notifying the supervisory authority (such as SDAIA in Saudi Arabia, the KVKK Board in Turkey, or the competent EU data-protection authority) and the data subjects is your responsibility as the Controller; we provide everything you need to do so.

Taking into account the nature of the processing and the information available to us, we assist you with:

• Data-protection impact assessments (DPIAs) where you need one for processing through the Platform.
• Prior consultation with the supervisory authority where required.
• Answering supervisory-authority enquiries relating to our processing.

Standard information (this Addendum, the Security and Subprocessors pages, and the description of processing in Annex 1) is available at no cost. If you request additional bespoke work beyond that, we agree a reasonable cost with you in advance.

Our providers are located in the United States and the European Union, so Customer Data may be transferred to or stored outside your country. We rely on the following safeguards:

• Standard Contractual Clauses (SCCs) or equivalent commitments from each provider.
• Least privilege: each provider receives only the data its function needs — the job queue carries identifiers, not message bodies, and the model provider receives the conversation context and the snippets needed for a reply, not the whole database.
• Model providers operate under commercial terms that prohibit training on your inputs and outputs.

If your country's law imposes additional conditions on cross-border transfers (such as the PDPL or the KVKK), we cooperate with you to document them.

We provide the information needed to demonstrate compliance with this Addendum:

• Written information about our controls and practices — once a year on request, plus answers to your security questionnaires within reasonable limits.
• Independent reports from our subprocessors (such as the audit reports they publish) on request, to the extent they are available to us.

On-site audits take place only when a competent supervisory authority demands one, or after a Data Breach that affected you. In both cases they are conducted with prior written notice, during business hours, within reasonable limits that protect the confidentiality of other merchants, and at your cost.

During the subscription, you control the retention period: from /dashboard/settings/data-rights you choose either to delete dormant conversations after a number of days you set, or to keep them permanently. Deleting a customer from the Customers page removes their data from the live systems.

When the subscription ends or the account is closed:

• Return: you can export all your data as a single JSON bundle from the same page (capped at 5,000 rows per collection, with a manifest stating what was excluded), plus CSV exports of customers, products, and orders. Encrypted credentials are never exported.
• Deletion: after a 30-day grace period (during which you can cancel the deletion), we permanently erase customers, orders, conversations, and integrations.
• Backups: retained for 7 days and then pruned, so any deleted data leaves the backups within 7 days at most.

After that we keep only what a mandatory law requires (such as billing records under accounting law), protected by the same controls. More detail on the Data deletion page.

Each party's liability under this Addendum is subject to the same limitations and exclusions of liability set out in the Terms & Conditions, which apply to the aggregate of all claims under the Terms and this Addendum together as a single cap. Nothing in this Addendum excludes any liability that Applicable Law does not allow to be excluded.

You are responsible for the lawfulness of your collection of Customer Data, for your legal basis for contacting the people it belongs to, and for your instructions to us. We are responsible for complying with this Addendum and with the obligations Applicable Law imposes directly on processors.

This Addendum takes effect when you accept the Terms and remains in force for as long as we process your customers' data, including the grace period and deletion after termination. The confidentiality obligations survive it.

In case of conflict, this Addendum prevails over the Terms in everything relating to the processing of personal data. If a local law requires additional processor clauses from you, we sign them with you and they prevail over this Addendum to the extent necessary. We notify you of any material change to the Addendum by email or in the dashboard 30 days before it takes effect.

• Encryption in transit: TLS/HTTPS on every interface with HSTS, an enforced Content-Security-Policy, and framing blocked (X-Frame-Options: DENY).
• Encryption at rest: every secret column (AI keys, store platform tokens, WhatsApp, Meta, and X credentials, two-factor secrets) is encrypted with AES-256-GCM; decrypted values are never logged or sent to the browser.
• Tenant isolation: every query is scoped to the organisation and store, the active store is re-verified server-side, and authorisation is never trusted from the client.
• Access control: RBAC with resource:action permissions that fail closed, suspended members cannot act, team invites by token link, and optional two-factor authentication (TOTP) with single-use backup codes.
• Authentication: passwords stored as bcrypt hashes or Google sign-in with a verified email, JWT sessions, and rate-limited login and two-factor attempts.
• Integration integrity: every webhook signature verified with HMAC-SHA256 and a timing-safe compare (Salla, Zid, Shopify, Meta, X, iyzico, Resend), and job-queue messages signature-verified.
• Abuse limits: rate limiting (Redis with a Postgres fallback, never failing open) and distributed locks.
• Data minimisation towards models: only the system prompt, the last 12 messages of the conversation, and the snippets needed for the reply (product descriptions capped at 200 characters, knowledge-base answers capped at 500 characters, order status) are sent to the model provider; never the whole database.
• Prompt-injection defence: externally sourced text (product descriptions, knowledge-base answers) is stripped of injection markers and fenced as untrusted content, and the model is instructed to treat it as data.
• Action guardrails: merchant-set autonomy levels with hard caps on refunds and discounts; any action over a cap goes to human approval; refund and cancellation tools verify that the order belongs to the requesting customer.
• Logging and monitoring: an audit log of sensitive operations (exports, permission changes, campaign sends, AI approvals, settings changes with before/after — never credentials) retained for 365 days; error monitoring via Sentry with no personal data by default.
• Uploaded files: validated by MIME allowlist, extension, and byte sniffing; images (jpeg, png, gif, webp) and PDF only.
• Continuity: a nightly database backup at 03:30 UTC to our own storage, retained for 7 days and then pruned; a model-provider failover chain that ends by handing the conversation to a human rather than going silent.
• Organisational: staff access limited to support and incident investigation, written confidentiality obligations, an internal dependency and security audit before launch, and a vulnerability-reporting channel at security@capiagent.com.

For data-protection questions: privacy@capiagent.com. For contract questions or to request a signed copy: legal@capiagent.com. For security incidents: security@capiagent.com. We reply within 5 business days at most. The other documents are on the Legal hub or via the contact page.