Where your ad platform credentials live, what an API key or an AI assistant can and cannot do with your account, and what we have and haven't been audited on.
Converly connects to your ad accounts and handles your leads' details, so it's fair to want to know exactly what it can reach and what it can't.
This article covers how your credentials are held, what access you can hand out, and the limits that apply to anything acting on your behalf.
Connecting an ad account
When you connect Google Ads, Meta or any other platform, the credential travels from your browser, through Converly's own authorisation window, and into Supabase Vault. That's a dedicated secrets store, kept separate from the database your conversions live in, and the key that protects it is held by the vault rather than sitting in Converly's own configuration. Your conversion database holds a reference to the credential and nothing more. It isn't returned by any API, it is never included in a response, and reading it is restricted to the single service that needs it to send your conversions.
You always complete the connection yourself. Converly can generate the link, but the sign in itself happens on the platform's own screen, so your password and the token it produces never pass through Converly's interface. This also means nobody should ever ask you to paste a token into a chat window, and Converly never will.
Each site holds one connection per platform. Connecting a different account for the same platform replaces the previous one.
You can read more about how conversion data itself is stored in What happens to personal data.
Conversions are only accepted from your own site
Every conversion carries the browser's own statement of which site it came from, which JavaScript cannot forge. Converly checks it against the domains on your account and rejects anything else. So someone who copies your tracking script onto their own website can't push conversions into your ad accounts.
Your subdomains are covered automatically, worked out from the public suffix list rather than from a list you have to maintain. So adding example.com also accepts app.example.com without accepting anything you don't own.
Important
This is also the most common silent misconfiguration. A site with no website address set rejects every conversion while everything else looks healthy. It is the first thing to check when a published flow captures nothing.
How your data is protected in transit and at rest
Everything travelling to or from Converly goes over HTTPS. That includes every call we make out to an ad platform or analytics tool, so there is no path anywhere in Converly that sends your data over an unencrypted connection.
The database holding your conversions is encrypted at rest, and your ad platform credentials sit in a separate encrypted vault rather than in that database. What happens to personal data covers what is stored, for how long, and when it is erased.
What an API key can do
If you're connecting your own tools to Converly, or building something against the API, you'll generate an API key. Here's how they work:
- They're server-side only. A key starts with
sk_live_and should be treated like a password. It belongs on your server, never in a web page or an app where a visitor could read it. - They're stored hashed. Converly keeps a SHA-256 hash rather than the key itself, so a key can never be recovered after it's issued, only replaced. If you lose one, you generate a new one.
- Access is granted per capability. A key gets the specific permissions you give it rather than everything your account can do, and every request re-checks the exact permission it needs.
- A key can be bound to a single site. So an integration built for one website can't read another site in the same account.
What an AI assistant can and cannot do
You can connect an AI tool like Claude or ChatGPT to your Converly account and have it build and manage your conversion tracking for you, which is covered in Setup. Handing an AI tool access to your ad accounts is a reasonable thing to be careful about, so the access it gets is deliberately narrower than your own.
Here's what an AI tool connected to your account cannot do:
- It can't retrieve your ad platform credentials. Not as a matter of policy, but because the permission that would allow it is excluded from assistant access entirely. It can build flows, publish them and read results, and it physically cannot read your Google Ads token.
- It can't connect an account on your behalf. It can generate the link and wait for you to finish, but the sign in happens on the platform's own screen. If an AI tool ever asks you to paste a token into the chat, something is wrong.
- It can't quietly put a test conversion into your reporting. Where a platform has a proper test mode it uses it. Where one doesn't exist, the test would create a real conversion in your campaign reporting, so the request is refused outright unless you explicitly agree to it first.
- It can't delete or disconnect anything casually. Removing a flow or disconnecting a platform means naming the exact thing being removed, rather than answering yes to a general question.
- It can't change your plan or delete a site.
- It can't read your leads' personal information. When an AI tool reads your conversion log it's told which fields were captured, not what they contained. No email addresses, no phone numbers, no IP addresses. That's enough to diagnose a matching problem and not enough to walk away with your customer list.
- It can't invent options. Form names, event types and conversions are all read from your real accounts. If your form tool isn't supported, it tells you so rather than improvising a workaround that looks like it worked.
Everything is attributed
Every consequential action on your account is recorded along with where it came from, so you can always tell whether a flow was published from the dashboard, the API, the CLI or an AI assistant. That matters most when more than one thing is touching your account, because "who changed this" is the first question when something looks different from how you left it.
API requests are logged separately for 90 days, including which key was used. The account and user are recorded at the time of the request, so the history stays readable even after a key has been revoked.
Other controls
- Rate limits apply per credential and per source, so one misbehaving integration can't exhaust your capacity.
- Webhooks are signed, and a signature is only valid for a short window, so a captured request can't be replayed later.
- Errors never return internal detail. A failure says what went wrong in terms you can act on, without describing our internals to whoever asked.
- Signing in is protected too. Resetting your password signs out every existing session, and sign-in links sent by email expire after 15 minutes and are stored hashed rather than in readable form.
- Two-factor authentication is available on every account. Once it's on, logging in with a password or an emailed sign-in link also needs a 6-digit code from an authenticator app, with 10 single-use backup codes in case a phone is lost. Turning it on signs out every other session, and changing it needs a login from the last 24 hours. Logins through Google or Webflow rely on that account's own security instead. Turn on two-factor authentication covers setup.
- Your leads' contact details are hashed before they are sent to any platform that requires it, so the platform can match the conversion without ever receiving a readable email address or phone number. The Normalization and hashing article covers exactly what each platform gets.
Certifications and audits
Automated security scanning. The code behind the dashboard and the service that receives and sends your conversions is scanned automatically by Aikido Security every 3 days. It looks for known vulnerabilities in the open source packages Converly uses, flaws in Converly's own code, and keys or passwords committed by mistake. The public website at converly.io is checked weekly. Every finding is reviewed, and critical and high severity issues are prioritised for fixing.
Penetration testing. Converly is penetration tested by an independent third party every year. The most recent test was carried out by IntegSec in September 2026 and covered the dashboard and the API. Every critical and high severity finding from that test has been fixed. The signed attestation letter is available on request from help@converly.io.
Certifications. Converly runs on infrastructure that holds SOC 2 Type II, but Converly itself is not independently certified. If your procurement process needs a certification, just ask. We are happy to walk you through where we are at and what we can share in the meantime.
Subprocessors. Converly relies on a handful of third-party services to operate, and the full list of what each one processes and where is published at converly.io/subprocessors. We notify customers before that list changes.
A data processing agreement is available on request. Email help@converly.io and tell us which jurisdiction you are contracting from, so we can send the right transfer terms with it.
Reporting a security problem
If you think you have found a vulnerability, email help@converly.io with "Security" in the subject line so it gets picked up quickly. We will acknowledge you and keep you posted while we work on it. Please give us a reasonable window to fix anything before disclosing it publicly.
