> ## 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.

# Security

> How Click to Call protects your visitors, your data, and your site

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](/guides/click-to-call/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](/guides/click-to-call/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](https://support.apifycloud.io). We
acknowledge good-faith reports and don't pursue legal action against
researchers who disclose responsibly under this channel.