Destinations

A destination is any tool Fidero delivers your events to: ad platforms like Meta and Google Ads, analytics like GA4 and Amplitude, lifecycle tools like Klaviyo, and your own warehouse. Every event that reaches Fidero is enriched, checked against consent and delivered to each destination your configuration enables.

You implement once. Your site and your servers send events to Fidero, and every destination is fed from that same stream – adding one changes nothing about your instrumentation.

You state the outcome

Destinations are enabled by outcome. You state what you want – “Send purchase conversions to Snapchat”, “Send subscription renewals to Braze” – and supply the credentials the tool needs. The mapping, formatting, hashing and deduplication each destination’s API expects are already built into the platform, so there is no per-event or per-property setup behind the request.

You provide	Built into the platform
Credentials – an API token, a pixel ID	The event and property mappings each tool expects
Identifiers a tool requires, like a Google Ads conversion action ID	Formatting, hashing and deduplication for each API
Overrides, where a default isn’t right for you	Consent enforcement and delivery monitoring

That’s the whole configuration surface. Why it can be that small is an architecture decision – the platform overview makes the case.

What every destination receives

However different the tools are, every destination gets the same treatment.

• Enriched events. Fidero re-attaches attribution and identity context before delivery, including to events that never touched a browser – a renewal, a webhook, a CRM change. How the pieces fit traces one event through it
• Consent, enforced per destination. An event reaches a third-party destination only when the user’s consent grants a category that destination requires. Your own warehouse is the exception – it’s your system of record, so it receives every event that reaches Fidero, regardless of consent state. Consent & privacy covers the model
• Deduplication. Conversions are counted once, keyed on transaction_id and applied through each destination’s own dedup mechanism. Where a tool takes both a browser tag and a server API (Meta, GA4), Fidero delivers on both paths and deduplicates them against each other
• Managed adapter updates. When a destination changes its API, we publish the update to our adapter on our end. Nothing for your team to accept, republish or redeploy
• Monitored delivery. Delivery is tracked per destination, and failures raise alerts instead of passing silently. What’s guaranteed versus measured is on Guarantees & coverage

Enabling a destination

1. Request the outcome. Tell Fidero what you want – “Send purchase conversions to Snapchat” – along with the tool’s credentials. Make the request the way you already work with us: email, Slack or your shared configuration repository

2. Your configuration updates on the server. Within 24 hours the destination is live in your project’s config: the credentials are in place and the platform’s built-in mappings are active

3. The change propagates by itself. The SDK and the endpoint pick up the updated configuration on their next request. Nothing ships from your side – no release, no redeploy

Changes travel the same route: switching an event off for one destination, rotating a token, adding an override. How we work covers the working model.

Your warehouse is a destination

The same enriched events stream to your own warehouse – BigQuery or Snowflake, provisioned in your own cloud account, under your own schema. It’s your system of record, so consent doesn’t gate it – the complete, attributed record of your customer data builds up in infrastructure you own.

Supported destinations

The current list lives on the integrations page: ad platforms, analytics, lifecycle tools, warehouses and webhooks.

All supported destinations Every tool Fidero delivers to, by category – and what each one receives.

Missing a tool you rely on? Ask – we’ll tell you where it stands.