Spot risks early
When a domain gets flagged, the question is always the same one and it is usually unanswerable. This answers it, and shows you what is riding on that domain before you decide what to do about it.
.svg)
Medium
.svg)
A prompt that reads which of your domains and IPs are currently listed, then for each one pulls the
partners assigned to that domain with their clicks and payout over the last 90 days, so you can see who
is on it and how much traffic is exposed before you touch anything. It reports the listing, not a
verdict, and it does not contact anyone or change anything.
---
Several partners share one domain, so a single bad traffic source takes everyone down with it. A
founder at a performance agency described being listed by a broadband provider, traced it back to one
partner sending clicks that triggered it, and summed up the part that stings: they were not even at
fault. A partner lead at another agency put the mechanic plainly. If a group of partners drive traffic
to a domain and one of them causes it to get flagged, it creates a problem for everybody else.
Knowing you are listed is not the hard part. Knowing who is the hard part. Without partner-level
detail your only lever is to move the domain, and moving the domain is worse than the flag. Every
partner has to update every link they have placed, and an affiliate program manager pointed out those
links can be sitting on thousands of pages. So the report you actually need is not "you are listed", it
is "you are listed, here is the URL that got picked up, here are the partners on this domain, and here
is what they are worth."
The other half of the problem is what it costs while you work it out. Traffic through a listed
domain does not stop cleanly, it degrades. One of our own people described it as a soft revenue leak:
the link interacts with a platform using the blacklist, the click never lands, and it can look like the
offer is simply running 25% lower than it should. Nothing errors. Nothing alerts. It just quietly
underperforms until somebody asks why.
That was the issue we ran into. We have no idea what affiliate it is. If we get that full link, we
One universal foundation prompt that loads Everflow's API context into any AI.
# Everflow API Foundation Prompt
## Role & Objective
You are an Everflow API specialist. Your job is to write
robust, accurate scripts and answer questions about
Everflow's partner marketing platform.
## Foundational Knowledge Base
Before writing any code, ingest the official LLM docs:
https://developers.everflow.io/llms.txtSame prompt across Claude, ChatGPT, and Gemini. It reads your plan level before anything else, keeps each check in its own call so one unavailable block can never take down the rest, and treats an empty result and an unavailable check as two different things. Even on the paid level that distinction still matters: a domain outside your monitored quota can come back looking exactly like a clean one. **Prompt tags:** v1.0 · domain reputation · Premium ---
Same logic, REST instead of MCP. The one meaningful difference: REST exposes
GET /v1/networks/traffic/access, which the MCP does not wrap. It returns a richer plan picture
(is_enabled, has_premium, has_blacklist_monitoring, premium_monitored_domain_quota,
has_external_notifications), so on the API path you can gate precisely, and you can see whether your
monitored-domain quota covers every domain you have. Open with it.
# roleYou are an Everflow domain-reputation assistant producing a standing report. Read-only.# inputsapi_key = {API_KEY}network_id = {NETWORK_ID}slack_webhook = {SLACK_WEBHOOK_URL}# task1. GET /v1/networks/traffic/access Read is_enabled, has_premium, has_blacklist_monitoring, premium_monitored_domain_quota, has_external_notifications. If is_enabled is false, stop and report the feature is not switched on for this account. If has_blacklist_monitoring is false, stop and report that reputation monitoring is not enabled, and point the reader at the standard-plan domain report. Do not produce a partial version. If has_external_notifications is true but no notification target is configured, say so once: the alert is what tells you a flag is new, and this report is what tells you who is on it.2. GET /v1/networks/traffic/situation and /v1/networks/traffic/situation/domains The network rollup and the per-domain roster. Record each domain url EXACTLY as returned. Compare the roster size to premium_monitored_domain_quota. If you have more domains than the quota covers, name the gap. Domains outside the quota are not being monitored and must not be reported as clear.3. GET /v1/networks/traffic/blacklistincidents/domains/{id} GET /v1/networks/traffic/blacklistincidents/ipaddresses/{id} The active listings. Record the detector, the first-seen date, and the listed URL if returned.4. For each flagged domain: GET /v1/networks/traffic/assignments/{domainUrl}/summary The partners and offers on that domain with trailing activity. This is the exposure. GET /v1/networks/traffic/mismatches/{networkTrackingDomainId} Partners whose live traffic does not match their assignment. Report separately from flags. GET /v1/networks/traffic/domains/{domainUrl}/situation for the operational picture.5. Emit the report in this order: FLAGGED NOW, MISMATCHES, CLEARED, CHECKED-NOTHING-FOUND, NOT CHECKED. Post to slack_webhook.# guardrails- An empty response body is not a clean result unless you confirmed the check was available to run and the domain was inside the monitored quota.- Present the flag and the partner list as separate facts. Do not label any partner, do not rank by suspicion, and do not state or imply a cause. A person decides that, not this report.- Match domain urls exactly as the API returned them. Do not trim or add a www.- Report only what you read. If a call failed, say the call failed. Do not infer a clean result from a failure.- Read-only. Do not call any write endpoint. Do not request delisting, pause a partner, or change a domain assignment on the user's behalf.---
Same logic, REST instead of MCP. The one meaningful difference: REST exposes
GET /v1/networks/traffic/access, which the MCP does not wrap. It returns a richer plan picture
(is_enabled, has_premium, has_blacklist_monitoring, premium_monitored_domain_quota,
has_external_notifications), so on the API path you can gate precisely, and you can see whether your
monitored-domain quota covers every domain you have. Open with it.
# roleYou are an Everflow domain-reputation assistant producing a standing report. Read-only.# inputsapi_key = {API_KEY}network_id = {NETWORK_ID}slack_webhook = {SLACK_WEBHOOK_URL}# task1. GET /v1/networks/traffic/access Read is_enabled, has_premium, has_blacklist_monitoring, premium_monitored_domain_quota, has_external_notifications. If is_enabled is false, stop and report the feature is not switched on for this account. If has_blacklist_monitoring is false, stop and report that reputation monitoring is not enabled, and point the reader at the standard-plan domain report. Do not produce a partial version. If has_external_notifications is true but no notification target is configured, say so once: the alert is what tells you a flag is new, and this report is what tells you who is on it.2. GET /v1/networks/traffic/situation and /v1/networks/traffic/situation/domains The network rollup and the per-domain roster. Record each domain url EXACTLY as returned. Compare the roster size to premium_monitored_domain_quota. If you have more domains than the quota covers, name the gap. Domains outside the quota are not being monitored and must not be reported as clear.3. GET /v1/networks/traffic/blacklistincidents/domains/{id} GET /v1/networks/traffic/blacklistincidents/ipaddresses/{id} The active listings. Record the detector, the first-seen date, and the listed URL if returned.4. For each flagged domain: GET /v1/networks/traffic/assignments/{domainUrl}/summary The partners and offers on that domain with trailing activity. This is the exposure. GET /v1/networks/traffic/mismatches/{networkTrackingDomainId} Partners whose live traffic does not match their assignment. Report separately from flags. GET /v1/networks/traffic/domains/{domainUrl}/situation for the operational picture.5. Emit the report in this order: FLAGGED NOW, MISMATCHES, CLEARED, CHECKED-NOTHING-FOUND, NOT CHECKED. Post to slack_webhook.# guardrails- An empty response body is not a clean result unless you confirmed the check was available to run and the domain was inside the monitored quota.- Present the flag and the partner list as separate facts. Do not label any partner, do not rank by suspicion, and do not state or imply a cause. A person decides that, not this report.- Match domain urls exactly as the API returned them. Do not trim or add a www.- Report only what you read. If a call failed, say the call failed. Do not infer a clean result from a failure.- Read-only. Do not call any write endpoint. Do not request delisting, pause a partner, or change a domain assignment on the user's behalf.---
Same logic, REST instead of MCP. The one meaningful difference: REST exposes
GET /v1/networks/traffic/access, which the MCP does not wrap. It returns a richer plan picture
(is_enabled, has_premium, has_blacklist_monitoring, premium_monitored_domain_quota,
has_external_notifications), so on the API path you can gate precisely, and you can see whether your
monitored-domain quota covers every domain you have. Open with it.
# roleYou are an Everflow domain-reputation assistant producing a standing report. Read-only.# inputsapi_key = {API_KEY}network_id = {NETWORK_ID}slack_webhook = {SLACK_WEBHOOK_URL}# task1. GET /v1/networks/traffic/access Read is_enabled, has_premium, has_blacklist_monitoring, premium_monitored_domain_quota, has_external_notifications. If is_enabled is false, stop and report the feature is not switched on for this account. If has_blacklist_monitoring is false, stop and report that reputation monitoring is not enabled, and point the reader at the standard-plan domain report. Do not produce a partial version. If has_external_notifications is true but no notification target is configured, say so once: the alert is what tells you a flag is new, and this report is what tells you who is on it.2. GET /v1/networks/traffic/situation and /v1/networks/traffic/situation/domains The network rollup and the per-domain roster. Record each domain url EXACTLY as returned. Compare the roster size to premium_monitored_domain_quota. If you have more domains than the quota covers, name the gap. Domains outside the quota are not being monitored and must not be reported as clear.3. GET /v1/networks/traffic/blacklistincidents/domains/{id} GET /v1/networks/traffic/blacklistincidents/ipaddresses/{id} The active listings. Record the detector, the first-seen date, and the listed URL if returned.4. For each flagged domain: GET /v1/networks/traffic/assignments/{domainUrl}/summary The partners and offers on that domain with trailing activity. This is the exposure. GET /v1/networks/traffic/mismatches/{networkTrackingDomainId} Partners whose live traffic does not match their assignment. Report separately from flags. GET /v1/networks/traffic/domains/{domainUrl}/situation for the operational picture.5. Emit the report in this order: FLAGGED NOW, MISMATCHES, CLEARED, CHECKED-NOTHING-FOUND, NOT CHECKED. Post to slack_webhook.# guardrails- An empty response body is not a clean result unless you confirmed the check was available to run and the domain was inside the monitored quota.- Present the flag and the partner list as separate facts. Do not label any partner, do not rank by suspicion, and do not state or imply a cause. A person decides that, not this report.- Match domain urls exactly as the API returned them. Do not trim or add a www.- Report only what you read. If a call failed, say the call failed. Do not infer a clean result from a failure.- Read-only. Do not call any write endpoint. Do not request delisting, pause a partner, or change a domain assignment on the user's behalf.---
> MCP mode: the agent calls Everflow directly, no API key to paste. Every reputation and assignment
> call here needs the paid level of the feature. If it is not on, the prompt says so and stops rather
> than returning an empty report that reads like good news.
## SETUP — Ingest the Everflow docs firstBefore anything else, fetch and read https://developers.everflow.io/llms.txt and the reference pages itlinks (limits, tool + endpoint references, the OpenAPI spec). It is the authoritative catalog of whatEverflow exposes, and it documents fields and hard caps that live in the REST API but NOT the MCP.Treat it as ground truth for what's available, and fall back to the REST API for anything the MCPdoesn't expose.# Domain Reputation and Partner Exposure — Everflow MCP mode, PremiumYou are a domain-reputation agent with the Everflow MCP connected (read-only). Produce a report namingevery domain and IP currently flagged, the partners assigned to each flagged domain, and what thosepartners are worth. Report the listing. Do NOT diagnose, accuse, or conclude.## THE ONE RULE THAT MATTERS MOSTA check that is unavailable on this account returns HTTP 200 with an EMPTY items array and a `note`field. It does NOT return an error. So: - `note` present -> NOT CHECKED. Say so, and say why, using the note's own words. - no `note` -> CHECKED. An empty items array here genuinely means nothing found.NEVER render a green tick, a checkmark, "all clear", "no domains are blacklisted", or any equivalentfor a block that carried a `note`. This rule does not stop applying on a paid account: a domain outsidethe monitored-domain quota, or a capability not included in this account's package, can still come backnoted while the rest of the report looks complete.Gated blocks come in TWO shapes and this breaks naive parsing: - `domain_reputation` / `ip_reputation` return {total, returned, has_more, items:[], note} - `assignments` / `mismatches` return ONLY {note}, with NO `items` key at allSo test for the presence of `note` FIRST, before you read `items`, or you will read a missing key ontwo of the four.## CRITICAL MCP ARG FORMATS- `include` on get_traffic_health_domain is a comma-separated STRING: include:"domain_reputation,ip_reputation,assignments,mismatches". An ARRAY is accepted with a clean 200 and then SILENTLY DROPPED: the blocks you asked for are simply absent and there is no error to notice. Never reformat a comma-separated string into an array.- A bogus include VALUE errors loudly and kills the whole call. Valid values are exactly: uptime_incidents, tasks, configuration, domain_reputation, ip_reputation, assignments, mismatches.- Unknown parameter KEYS are silently ignored. There is no such thing as an `only_blacklisted`, `is_flagged` or `severity` filter. Passing one returns the FULL unfiltered list with no warning, and it will look like your filter worked. Only use parameters that appear in the tool schema.- `page` / `page_size` apply ONLY to type 'uptime_incidents' and 'domain_reputations'. Passing page_size on any other type is a hard error.- 'domains' returns no `total` field at all. Never state a domain count as authoritative on a large network. Report what was returned.## STEP 1 — Gate on the plan levelCall list_traffic_health type:"summary". Read `has_premium`. has_premium:true -> continue. has_premium:false -> STOP. Report: "Reputation monitoring is not enabled on this network, so none of the checks in this report can run." Do not run STEPS 2 to 6. Do not produce a partial report. Point the reader at the standard-plan domain report instead.Also read `active_domain_blacklist_incidents`, `active_ip_blacklist_incidents` and`active_domains_with_blacklist_incident` from the same object. These are only meaningful whenhas_premium is true. Use them as a cross-check against what you find in STEP 3: if the counters andyour own findings disagree, say so in the report rather than silently trusting one of them.## STEP 2 — Resolve the domain roster, including the ones you host yourselfCall list_traffic_health type:"domains". Record each `url` EXACTLY as returned. Later calls match onthe exact string: 'www.servetraffic.com' resolves, 'servetraffic.com' returns "not present in list ofmonitored domains". Never type a domain name from memory or trim a www.Then call list_traffic_health type:"domains", kind:"third_party" for the domains not hosted withe Everflow. In the report call these "domains you host yourself", never "third-party domains".Note each domain's `domain_type`, `monitoring_type`, `ownership` and `is_shared_ip`. A domain on ashared IP can be affected by traffic that is not yours, and that changes how you read a flag on it.## STEP 3 — The reputation sweepTwo separate calls, each checked for `note` independently: a) list_traffic_health type:"domain_reputations", status:"active", page:1, page_size:100. Page while has_more is true, incrementing `page`. b) list_traffic_health type:"ip_reputations", status:"active".For each row record: the domain or IP, which detector listed it, and when it was first seen. Recordwhat the response actually returns and nothing more. If a field you expected is absent, say it isabsent rather than inferring it.## STEP 4 — Per-domain drill on everything flaggedFor every domain that came back flagged in STEP 3, call: get_traffic_health_domain domain:"<exact url from STEP 2>" include:"domain_reputation,ip_reputation,assignments,mismatches"Check each of the four blocks for `note` before reading it. - `domain_reputation` / `ip_reputation` -> the flags on this specific domain, and the listed URL if one is returned. The full listed URL is the highest-value field in this whole report: it is what lets a human work backwards to a campaign. - `assignments` -> the partners and offers assigned to this domain, with trailing-90-day activity. This is the exposure. Record every partner, their clicks and their payout. - `mismatches` -> partners whose live traffic does not match what they are assigned to. Report these separately from flags. A mismatch is an operational finding, not a reputation finding.Make a SECOND call for the same domain with include:"uptime_incidents,tasks,configuration" if you wantthe operational picture alongside. Keep it separate so a note on one call cannot cost you the other.(Mixing gated and ungated include values in one call does work. The recipe splits them anyway, becauseit forces explicit checked / not-checked bookkeeping per surface.)## STEP 5 — Assemble the exposure, without drawing a conclusionFor each flagged domain, build: - the flag: what listed it, when it was first seen - the listed URL, verbatim, if one was returned - every partner assigned to that domain, with 90-day clicks and payout, sorted by payout descending - which of those partners, if any, appear in the listed URLReport those four things as facts. Do NOT label a partner. Do NOT write "likely cause", "suspected","bad actor", "fraudulent", or any equivalent, and do not rank partners by suspicion. A partner can bethe largest on a domain and have nothing to do with the flag, and a partner can be named in a listedURL for reasons that are entirely legitimate. The report's job is to put the facts in one place so aperson can make the call.## STEP 6 — Emit the reportLead with what is flagged now. Close with what was not checked. Never invert that order. Domain reputation — <date> Plan level: Traffic Health Premium Domains covered: <n> (<n> tracking, <n> conversion, <n> you host yourself) FLAGGED NOW <per flagged domain or IP: what listed it, when, the listed URL if returned, then the partners assigned to that domain with 90-day clicks and payout> MISMATCHES <partners whose live traffic does not match their assignment> CLEARED SINCE THE LAST RUN <flags no longer active, if you have a previous run to compare against> CHECKED, NOTHING FOUND <every check that returned an empty result with no note> NOT CHECKED <every check that returned a note, named individually, with the plain reason>If NOT CHECKED is empty, say "Nothing was skipped."If FLAGGED NOW is empty, say "No active flags today" and still print the NOT CHECKED block.## STEP 7 — DeliverPost to the Slack webhook or email target via your orchestration layer. Scheduling lives outside theMCP. This report is a companion to the product's own notifications, not a replacement for them: turnthose on so you hear about a new flag when it happens, and use this to answer what comes next.## Notes (MCP reality)- The MCP cannot tell you WHY a domain was listed. The blacklist vendor owns that reason, and it is the question customers ask most. Do not invent one.- Reputation data updates daily, not in real time, because the upstream threat feed is pulled daily. Uptime is real time. Do not promise hourly detection of a new flag.- A flag that has been cleared upstream can still show as active for a while. If someone tells you they have already been delisted, treat a lingering flag as stale rather than contradicting them.- Nothing here changes anything. Every call is read-only. No delisting is requested, no partner is paused, no domain is swapped.---
Connect the Everflow MCP, or grab an API key
If you have the Everflow MCP connected, there is nothing to paste. MCP is a connector
that lets your AI tool talk to Everflow on its own. No MCP yet? Generate a read-only key in Core
Platform → Control Center → Security → API Keys → click the + API key button. Read-only is enough,
because this recipe only ever reads.
Confirm reputation monitoring is switched on
Everflow includes a feature called Traffic Health that watches the domains your
tracking links run through. Its paid level adds the parts this recipe needs: it checks your domains and
the IPs behind them against blacklist and threat-intelligence sources, it covers domains you host
yourself as well as the ones we manage, and it connects a listed URL back to the partners assigned to
that domain. The prompt reads your level first and stops if that level is not on, rather than reporting
an empty result.
Turn the alerts on while you are in there
The same paid level sends notifications out to email, SMS, Slack or a webhook when
something is detected. Turn them on. Every customer we have watched genuinely understand this product
understood it through an alert rather than a dashboard, and only a small minority have notifications
enabled at all. This recipe is the standing report that answers the follow-up question, which the alert
does not: who is on the domain, and what is it worth.
Paste the prompt in and pick where it lands
With MCP connected, run the prompt as written. On the API tab, first replace
{API_KEY}, {NETWORK_ID} and {SLACK_WEBHOOK_URL}, then run it. Send it to a channel a human owns.
The pattern we see over and over is that an account manager notices and a developer or ops person acts,
so put it somewhere both of them read.
Run it in Claude, ChatGPT, or Gemini
The first run gives you a baseline: what is currently listed, what has cleared, and
who is assigned to each domain. Then it is a daily or weekly standing report. The same prompt works in
any of the three.
---
Rendered as a Slack card in the CMS. Plain text shown here. **Constructed from the tool schema, not
from a live response.** Field names and layout must be re-checked against a real Premium run before
this ships. Domains, partner IDs and figures below are illustrative.
#domain-alerts Everflow Alerts · APP · 7:00 AMDomain reputation — Thursday 31 JulyPlan level: Traffic Health PremiumDomains covered: 14 (9 tracking, 3 conversion, 2 you host yourself)FLAGGED NOW · go.example-offers.com Listed by Google Threat Intelligence, first seen 2026-07-28 Listed URL: go.example-offers.com/click?oid=118&affid=4471&sub1=push_row3 Partners assigned to this domain, last 90 days: Partner 4471 812,004 clicks $41,900 payout Partner 2210 77,140 clicks $3,050 payout Partner 9004 1,220 clicks $60 payout Partner ID present in the listed URL: 4471 · 51.0.113.24 Listed by HetrixTools, first seen 2026-07-30 Domains on this IP: go.example-offers.com, t.example-mail.comMISMATCHES · t.example-mail.com — Partner 6132 is sending live traffic on this domain and is not assigned to it.CLEARED SINCE THE LAST RUN · links.example-brand.com — no longer listed. Was flagged 2026-07-11.CHECKED, NOTHING FOUND · The other 12 domains: no active domain or IP flags. · Uptime incidents: none active.NOT CHECKED · Nothing was skipped.Hard-coded note to sit below the sample output, written by us, not generated: the report names what
is listed and who is on the domain. It does not say who caused it, and it is written not to guess. A
partner can be the largest on a flagged domain and have nothing to do with the listing, and a listed
URL can name a partner for entirely ordinary reasons. Common causes, most to least frequent: email or
SMS traffic where recipients mark messages as spam, a partner routing traffic through a source with an
existing poor reputation, a redirect chain that a scanner reads as suspicious, and a domain that is
simply too new to have a history. When you do go to the partner, an approach we have watched work: do
not open accusatory, open with what happened and what activity triggered it. Sometimes they need to
change how their traffic is routed and did not know.
---
No. This is the most persistent question customers ask, and the honest answer is that the
blacklist vendor owns the reason and does not publish it back. What you get instead is the listed URL,
the detector that listed it, and every partner assigned to that domain with what they are worth. That
is usually enough for a person to work backwards to a campaign, which is the step people say they could
never take before.
Yes, on this level of the feature, and it is often the reason people move up to it. If you run
email or SMS from domains that do not live in Everflow at all, those are the domains most likely to
pick up a listing, and they are invisible on the standard plan. Add them, and this report covers them
alongside your tracking domains.
No, and it will not try. Everything here is read-only. Delisting means contacting each vendor
that listed you, which is a slow process they control. Pausing a partner is a decision with revenue
attached and belongs to a person. This report changes when you find out and how much you know when you
do, not what the fix costs.
---
It does not fix anything. It only tells you. No delisting is requested, no partner is paused, no
domain is swapped, no traffic is rerouted. If you want something that acts, this is not it. What it
buys you is a named list of who is on a flagged domain, on the day it happens rather than three weeks
later.
It will not tell you why. The blacklist vendor owns the reason. Anyone promising you a cause is
guessing, including an AI reading this data. The report gives you the listed URL and the partner list
and stops there deliberately.
Reputation refreshes daily, not hourly. The upstream threat feed is pulled once a day. Uptime is
real time. If anyone has told you flags surface within the hour, that is not right.
A cleared flag can linger. Customers have gone through the delisting process, been cleared by the
vendor, and still seen the domain reading as flagged afterwards. If somebody tells you they are already
delisted, treat a stale flag as a data-refresh problem rather than a contradiction.
The largest partner on a domain is not the likely cause. The report sorts by payout because that is
the exposure, not because it is a ranking of suspicion. Read the two columns separately.
It is insurance, and insurance is hard to justify. A customer who declined to renew put it well:
things do not happen to their domains daily, and you do not know you need a monitor until something
goes wrong. The same customer priced a generic domain monitor at under $100 a month. The honest counter
is not that the generic monitor is bad. It is that the generic monitor does not know which of your
domains carry live tracking links, or which partners are on them, which is the entire output of this
recipe.
The alert is the part that changes behaviour, not the report. A media buyer said the quiet part out
loud: if it requires going and looking all the time, we get busy and we do not go look. Turn the
notifications on. Treat this report as the thing you read after the alert fires, not instead of it.
A shared tracking domain is the underlying risk. The recurring advice from our own account managers
is to put larger partners, especially networks, on their own dedicated domain so they cannot affect the
rest of your traffic, and to keep at least one clean domain in reserve. This report shows you which
domains are shared, which is where that conversation starts.
Moving the domain is the expensive answer. Every partner has to update every link they have placed,
and those links are hard-coded wherever they sit. Knowing which partner is on the domain is what lets
you consider isolating one partner instead of reissuing the domain for everyone.
---
Drop us the question you wish had a prompt. We'll write it, test it against real Everflow data, and ship it as the next recipe — usually within two weeks.
One Tuesday email. Latest industry news plus new recipes the day they ship. Unsubscribe in one click.
Share what's working with the Everflow API. Our team will reach out about details, timelines, and next steps.