Security

Documentation Index

Fetch the complete documentation index at: https://docs.apifycloud.io/llms.txt

Use this file to discover all available pages before exploring further.

Click to Call is built with the understanding that it runs on arbitrary websites, talks to live visitors, and handles voice — a category of data that most privacy frameworks treat as sensitive. This page explains the technical controls that keep the widget safe to deploy.

​

Call audio in transit

Voice media travels over DTLS-SRTP end-to-end between the visitor’s browser and our infrastructure. Signalling runs over TLS 1.2+ with modern cipher suites. Audio captured on the network without the session keys is unintelligible. The widget itself is served over HTTPS only; modern browsers reject microphone access on any insecure page before audio is ever captured.

​

Call recording

The Click to Call widget does not record call audio. No audio stream is captured, stored, or proxied on our side. If your contact centre records on its own side (e.g. on the SIP trunk it terminates calls on), that recording and its handling are governed by your contact centre’s policy — not by ApifyCloud. You’re responsible for any consent and retention obligations that apply.

​

Data the widget processes

The widget collects visitor IP and user-agent (for fraud prevention and rate limiting), call metadata (IDs, duration, timestamps), any voluntary content you pass in via URL context or the pre-call form, and the live audio stream for the duration of a call. See Compliance for the full breakdown and lawful-basis guidance.

​

Data retention

Retention for call metadata, survey responses, and event deliveries is defined per contract. Retention windows are agreed with each customer — there is no one-size-fits-all default. For deletion requests on specific records, contact support.

​

Custom code sandbox

When you inject HTML / JavaScript into the widget, the code runs inside an iframe with sandbox="allow-scripts" and no allow-same-origin. Because the sandbox has an opaque origin, the script:

• Cannot read cookies or localStorage on your site or on apifycloud.io.
• Cannot read or modify the widget’s DOM.
• Cannot navigate the top-level window.
• Cannot call our APIs with the visitor’s credentials.

Communication between custom code and the widget happens exclusively over postMessage. See Custom code.

​

Parent-frame events

When the widget is embedded as an iframe, it can emit events to the parent page via postMessage. The widget only delivers events to origins you’ve allowlisted for your widget in the console (Call Studio → Embed). Default is deny — with no allowlist configured, no events cross the frame boundary at all. Custom code and server-side integrations still receive events — only the cross-frame boundary is gated.

​

Visitor data boundaries

Everything the widget forwards to custom code, integrations, and parent pages is filtered:

• Internal credentials (session tokens, voice-infrastructure tokens) are never exposed.
• URL context passed in query params is sanitised — keys must match a safe pattern, each value is capped, and a total budget applies per session.

These caps also stop malicious links from flooding your analytics or webhook endpoints with oversized payloads.

​

Integration secrets

When you configure a webhook integration with auth headers or signing keys, those values are encrypted at rest (AES-256-GCM). They are only decrypted in memory for the duration of a delivery and are never sent back to the browser. Revealing a stored secret in the console is rate-limited and produces an audit trail.

​

Rate limiting & abuse protection

Public endpoints (widget load, session token, event ingest) are rate-limited per IP and per app. These limits protect your account against brute-force enumeration and abuse of your widget URL. They are not visible during normal usage.

​

Tenant isolation

Each app is a separate tenant. Data access is scoped to the app identified on every request — cross-tenant reads or writes are impossible by construction, and every database query includes the tenant identifier as part of its predicate.

​

Reporting a vulnerability

If you believe you’ve found a security issue in Click to Call, please report it to our support channel. We acknowledge good-faith reports and don’t pursue legal action against researchers who disclose responsibly under this channel.