Data protection and security

This page summarises how Zitena protects your customers’ data and your credentials. For retention periods and KVKK (Turkey’s data protection law) obligations see Privacy and retention.

Encryption

Data	How it is stored
Integration records (store keys, SIP password, SMS/SMTP details, İYS and coupon provider keys, AI keys, inbound webhook secret)	Symmetrically encrypted (Fernet); write-only — the API and console only show whether it is set and the last four characters
Customer phone numbers (calls, requests, orders, site order records, carts, customer records, outbound call requests)	Encrypted copy + company-specific hash for matching + masked value for display. The plain number is not stored
Do-not-call list	Only a company-specific HMAC-SHA256 hash; irreversible, the list is never shown
API keys	Only the SHA-256 hash and last four characters; the plain key is shown once
Webhook secrets	Encrypted; shown once when created
Button tokens	Signed with a key derived from the server key, valid for at most 15 minutes, single-use

Searching orders or calls by phone uses the number’s hash; full numbers are never compared in plain text in the database.

Masking

• Console: phone fields in lists are always masked (+90 532 *** ** 67). The Viewer role never sees full numbers.
• Event and call records: phone numbers are masked when written; tools’ own masking is the first line of defence, masking on the event path the second.
• After-call analysis: for topic tagging, summaries and outcome inference, emails, phone numbers, spaced digit groups, long numbers and address fragments ([ADRES]) are masked before the transcript reaches the language model. The model is also asked for anonymous output for customer names; the summary is masked again.
• Live calls: this masking does not apply to the live call. During the call, speech recognition and the language model receive what the customer says without masking; that is how the assistant can answer. Sub-processors →
• The assistant’s order summary: contains no phone, email or address.
• Data API and webhooks: phone, name and transcript are masked by default; if the company admin turns on Personal data, full values are returned. Emails in outbound call events are always masked.
• Notification log: recipient masked; only the template name and (masked) variables are stored as content.
• Logs: phone numbers, secret values, webhook bodies and response content are never logged.

Company isolation (RLS)

Each company’s data is isolated with PostgreSQL Row Level Security: every company-owned table has a policy that only lets a row be read or written if it matches the transaction’s company context. Each request runs in its company’s context, set per transaction and reset when the transaction ends. Background workers (scheduler, webhook sending) read the queue across companies but process each record in its own company’s context.

When a resource belongs to another company, the API returns 404; its existence is not revealed (e.g. an unknown company on the inbound webhook).

Credentials

• Secret fields are write-only: after saving they never come back in any response. A secret field sent empty keeps the old value.
• The change history only records the names of changed fields, never values.
• You can enter your own AI keys (OpenAI, Anthropic, ElevenLabs, Deepgram); otherwise the platform key is used.
• For providers that write to live systems (consent provider, coupons), only .test addresses are used while Allow live address is off; TLS verification can only be turned off for .test domains.

Network security

• Outbound webhooks, data feeds, generic HTTP SMS and SIP server addresses pass an SSRF check: https only (a public address for SIP), the address is resolved again on every request, and requests to private/local/reserved IPs are never made. Redirects are either not followed or re-checked at every hop.
• Webhooks and inbound webhooks are signed with HMAC-SHA256, with a ±300 s timestamp tolerance and replay protection by delivery id.
• The button’s CORS is only open to the publishable key’s allowed domains.

Support mode

The support team can enter your company only in support mode: read-only by default; editing needs a reason and a grant limited to 15/30/60 minutes; every action is written to the Change History. Support mode →

Your responsibility

Keep API keys and webhook secrets only on your servers, rotate them regularly and revoke unused ones. When you turn on Personal data, full phone numbers go to your systems; protecting that data is your responsibility.