Your conversion data, readable by your own tools and your own agents
Every conversion you send through DataFirefly can be read back: a signals API for your scripts and dashboards, and an MCP server so Claude or ChatGPT can answer questions about your own conversions instead of guessing.
Read-only by construction, scoped to your account by the token itself, and identifiers are reported as presence, never value. An agent can tell you how last week converted without ever seeing a customer's email.
Your conversion data ends up everywhere except in your hands
You send the same conversion to five platforms. Each one keeps its own version, in its own dashboard, behind its own login and its own attribution model.
Five dashboards, five truths
Meta counts one thing, Google Ads another, GA4 a third. Reconciling them is a spreadsheet exercise you redo every month, and nobody on the team enjoys it.
Nothing to point a tool at
Want to chart delivery over time, alert on a drop, or hand the numbers to an assistant? There is no endpoint to call. You export a CSV by hand, or you do without.
And the moment you export, you own the risk
A CSV of conversions with emails in it is personal data on a laptop. The easiest way to read your own data is also the one that creates a problem you did not have.
"AI-ready" is a claim. Here is the version that can be checked.
Plenty of tools say their data is ready for AI. The question worth asking is narrow: can something that is not a human open it, and what does it see?
There is an address to call
A documented HTTP endpoint, a bearer token, JSON out. Not a screen to scrape, not a report emailed on the first of the month.
An agent can use it without a plugin
The same reads are exposed over the Model Context Protocol, the convention assistants already speak. You paste one block into your client and it can ask.
And it sees nothing it should not
The records returned are the redacted ones: identifier presence, never identifier values. Giving an assistant access does not hand it your customer list.
One token, three ways to read the same signals
Summary
Volume, delivery per destination, latency, and the share of events carrying a strong identifier over a window you choose, up to 31 days. That last number is what drives match quality, and it is computed without holding one identifier in clear.
Events
The redacted stream, up to 500 records, filterable by event name or on failures only. The same records the Event Inspector shows you in the console, with the same redaction.
MCP
The same two reads spoken over the Model Context Protocol, as the tools
signals_summary and signals_events. Your assistant
answers about your conversions instead of about the internet's.
The account comes from the token, never from an argument. There is no parameter an agent could be talked into changing to read somebody else's data: a made-up account name in an MCP call changes nothing, and a test proves it.
Three steps, and nothing to install
Generate a token
In your client space, on the site you want to read. Nothing is readable until you do: the token is null until you create one, and revoking it takes effect immediately, not at the next cron.
Paste it where you need it
A curl command for your scripts, or the MCP block for Claude or ChatGPT. Both are shown ready to copy on the same page as the token.
Ask
"Which destination failed most this week?" "Did match coverage drop after Tuesday?" "Show me the purchases that were skipped and why." Your assistant reads your own numbers to answer.
Export a CSV, build a warehouse, or read the API
All three end with numbers you can work on. They differ in what you have to run, and in what leaves your account.
| Manual export | Data warehouse | DataFirefly signals API | |
|---|---|---|---|
| To set up | A download, every time | A pipeline, a schema and a bill | A token, once |
| Freshness | As old as the last export | As fresh as the last sync | Live, up to the last 31 days |
| Personal data | A file with emails in it | Whatever you chose to load | Presence only, no values |
| Usable by an agent | Only if you paste the file | With a connector you write | Natively, over MCP |
| Write access | None | Whatever the credentials allow | None by construction |
When another route suits you better. If you already run a warehouse and your conversions have to sit next to your margin and your stock, load them there: this API is a read of one system, not a replacement for a modelled warehouse. It is the shortest path when what you want is to see, alert on, or ask about your own conversions.
Whatever sends the events, the read is the same
PrestaShop
A native module that sends the whole funnel, with session stitching and consent handling built in.
WooCommerce
A WordPress plugin with a retry queue, an Activity panel and HPOS compatibility.
Shopware 6
A Shopware plugin covering the same funnel, connected with the same single key.
Shopify
Shopify's order webhooks, subscribed in minutes with the same single key. Nothing to add to the theme.
A headless front-end or a custom stack? Send your events to our API: the dispatcher treats every source the same, and the signals read back the same way. Tell us about your setup.
Giving an assistant access should not mean giving it your customers
Read-only, by construction
There is no write path behind this token. It cannot change a destination, replay an event or touch a subscription.
Presence, not values
An event says whether it carried an email, not what the email was. The country is there because a country on its own is not personal data.
Hosted in the EU
The read happens on the same EU infrastructure as the tracking. Nothing crosses a border to answer a question.
Revocable immediately
One click and the token stops working on the next request, not at the next scheduled job.
Questions worth asking before you open anything
Does the AI see my customers' personal data?
No. The records returned are the redacted ones: each event says whether it carried an email, a phone number, a name or an address, never what they were. An assistant can tell you that match coverage fell on Thursday without ever being able to name a customer.
Can an agent break something with this token?
There is no write path behind it, so no. And the account it reads comes from the token itself: there is no parameter for an agent to be persuaded to change. Prompt injection can make an assistant ask a strange question; it cannot make this API answer for somebody else's account.
How far back can I read?
Up to 31 days for the aggregates, and the last 500 events for the stream. It is a live read of the dispatcher's own window, not an archive: if you need years of history, that is what a warehouse is for, and you can feed it from here.
Which assistants can use it?
Any client that speaks the Model Context Protocol, which today includes Claude and ChatGPT among others. We publish a standard MCP endpoint rather than an integration per vendor, so a new client that speaks the protocol works without us shipping anything.
Is it an extra cost?
No. It is part of every plan, including the free one. Reading your own data back is not a feature we think should be sold separately.
Do I have to use AI at all?
Not at all. The same token answers a plain HTTP call, so it is just as useful for a dashboard, a weekly alert or a script that checks delivery every morning. MCP is one way in among others.
Your signals are already there. Open them when you want.
Create an account, connect your shop, and generate a token the day you need one. Nothing is readable before that, and one click closes it again.