Skip to content

Privacy and redaction in the API

The fields the Convultra API strips from every payload, the geography floor, path-only URLs, and what conversion rows deliberately do return.

article |4 min |Updated Sep 2026
On this page · 5 sections

The Convultra API and MCP server are in Beta. Their output ends up in warehouses and AI transcripts, so redaction happens centrally, in one reviewable list, rather than as a property forty handlers have to maintain. This page is the boundary: what is stripped, what is reduced, and what conversion rows carry on purpose.

Fields stripped from every payload

These field names are removed at every nesting depth:

ip_address        ip                user_agent        userAgent
fingerprint       latitude          longitude         user_id
click_history     selected_click_id asn               org
sample_gclid      sample_fbclid     sample_msclkid    sample_gbraid
sample_wbraid     sample_referrer   sample_landing_page
sample_urls       key_hash          credentials       tinybird_token
access_token      refresh_token

So: no IP addresses, no user agents, no device fingerprints, no coordinates, no end-user ids belonging to your own site, and no credentials or tokens of any kind. Integration rows carry status and timing only; encrypted OAuth material never leaves the server, under any scope.

Reductions alongside the deny-list

  • URLs are reduced to paths. Query strings on tracked pages routinely carry order references, email addresses and session tokens that the site owner put there, so you get /checkout/complete, not the full URL. Referrers are reduced to a domain without www..
  • Geography rows below five sessions are suppressed. A city row with two sessions, combined with a timestamp and a landing page, can identify a person. Country, region and city breakdowns drop rows under the floor of 5 and report how many in meta.suppressed_rows, with the floor itself in meta.suppression_floor_sessions. The dashboard may still show those rows to the site’s own operator; the API does not.
  • PII presence flags collapse to one boolean. The six has_email, has_phone, has_first_name, has_last_name, has_address and has_user_data flags describe the personal data a customer’s site handed over, and “this buyer gave a phone number but no address” is a fact about a person, not a campaign. They become a single enhanced_conversion: true|false, which is the only part a marketer acts on.
  • Failure text is Convultra’s, not the platform’s. A raw platform error can echo back parts of the payload sent, which is where personal data lives. You get a plain-English reason sentence instead.
  • Customer-supplied text stays out of MCP summaries. Page paths, referrers, UTM values and campaign names appear only in the structured data an MCP tool returns, never in the prose summary a model reads first, because anyone can put text into a tracked site’s URL.

What conversion rows do carry, deliberately

Conversion rows do return ad click ids and the session id:

{
  "event_id": "evt_01JQ8Z4M2YTB6KQ",
  "click_ids": { "gclid": "EAIaIQobChMI...", "fbclid": null, "msclkid": null },
  "session_id": "sess_7Kq9mWx4Rn8s",
  "attribution": { "platform": "google_ads", "click_age_days": 11, "is_ai_referral": false, "ai_platform": null },
  "enhanced_conversion": true
}

This is a deliberate decision, and it needs no scope beyond conversions:read. These are your own tracked data, and a click id is the only way to reconcile Convultra’s conversion counts against Google’s and Meta’s, which is the entire job a reconciliation script exists to do. attribution.platform is derived from the click id alone and uses the same vocabulary as the delivery log, so the two join up.

The boundary, precisely: identifiers your ad platform already holds are returned; attributes of the person behind them are not. A gclid is Google’s own handle on a click. An IP address, a user agent, a fingerprint, a pair of coordinates or an email flag describes a human being. The first crosses; the second does not.

Sessions

You never supply a session id to get_conversion. The session is resolved server-side from the conversion, and no other session’s journey is reachable through this API.