Spot risks early
You almost never find out from a dashboard, you find out from a partner, weeks later. This runs the check every morning and posts it where your team already looks.
.svg)
Medium
.svg)
A prompt that reads every domain your links run through, checks whether they are up, whether their certificates are current, which dedicated IPs they resolve to, and whether any remediation work is sitting open, then posts a short morning digest to Slack. It closes by naming what it did not check, instead of showing you a green tick it did not earn.
You almost never find out from a dashboard. You find out from a partner. A partner emails to say their link is throwing an error, or their traffic to you has collapsed, and you go looking. By then it has usually been true for weeks. One affiliate manager in lead-gen heard it from the partner first, then opened the dashboard and found it had been reading healthy the whole time.
The reason it goes unnoticed is that a domain problem does not look like an outage. Nothing breaks. The site still loads for you. Traffic just thins out, on some networks and not others, and a slow decline looks exactly like a slow month. One partnerships lead put the shape of it plainly: only 15% really got through the link, which made them wonder whether they were missing out on partners who were not even clicking through, and they had no way to know.
The certificate case is even quieter, because it is nobody's job. A marketing ops lead at a financial publisher asked it straight on a call: the certificate expires in 47 days, is that something we update on our end, or does Everflow confirm it? That question going unanswered is the whole failure mode. One of our own people described a customer who got a two-week notice, then a one-week notice, was asleep at the wheel, and then one day the domain went down.
What people do about it today is close to nothing. A monitoring tool of any kind is named in a tiny fraction of conversations. Most teams check by hand when something feels wrong, which means the check happens after the damage. This recipe moves the check to a schedule so it happens before.
Only 15% really got through the link. It makes me wonder whether we are missing out on certain partners that aren't even clicking through, and we don't know.
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 it reads anything else, runs only the checks the standard level actually covers, and treats an empty result and an unavailable check as two different things. That last part matters more than it sounds: an unavailable check comes back looking exactly like a clean one.
Same logic, REST instead of MCP. The one meaningful difference: REST exposes the plan-level endpoint 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 tell "switched off entirely" apart from "on, standard level". Open with it.
# role
You are an Everflow domain-health assistant producing a daily digest. Read-only.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
slack_webhook = {SLACK_WEBHOOK_URL}
# task
1. GET /v1/networks/traffic/access
Read is_enabled, has_premium, has_blacklist_monitoring, has_external_notifications.
If is_enabled is false, stop and report that the feature is not switched on for this account.
If has_premium is true, say so in the header: this digest is the standard-level report and there is
a fuller one available for this account.
Otherwise carry has_premium = false forward and state the level in the digest header.
2. POST /v1/networks/traffic/situation and POST /v1/networks/traffic/situation/domains
Body: {} for both. NOTE these are POSTs. A GET returns Method Not Allowed.
The network rollup and the per-domain roster. Record each domain url EXACTLY as returned.
3. GET /v1/networks/traffic/tasks
Open remediation work. These lead the digest.
4. POST /v1/networks/traffic/usage/domains
Body: {"from":"<30 days ago>","to":"<today>"}
NOTE this is a POST. A GET returns Method Not Allowed.
Which partners and offers are actually using each domain, and how much money runs through it.
Returns offer_count, affiliate_count, relationship.assignment_count and a full reporting block
(clicks, conversions, payout, revenue, profit) per tracking domain.
Include it as context on any domain that appears in NEEDS ACTION, so the reader can see who is
affected and what is at stake. Verified live on a standard-plan network.
5. For each domain that is not up, or has an open task:
POST /v1/networks/traffic/domains/{domainUrl}/situation
Body: {}. NOTE this is a POST. A GET returns Method Not Allowed.
6. Do NOT call /v1/networks/traffic/blacklistincidents/* when has_blacklist_monitoring is false.
Record both blacklist endpoints as not checked, and name the reason.
7. Emit the digest in this order: NEEDS ACTION, WATCH, 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.
Gate every blacklist claim on has_blacklist_monitoring, not on an empty array.
- Certificate expiry filters include already-expired certificates. Compare dates yourself and split
ALREADY EXPIRED from EXPIRING SOON.
- 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, and do not request delisting on the user's behalf.Same logic, REST instead of MCP. The one meaningful difference: REST exposes the plan-level endpoint 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 tell "switched off entirely" apart from "on, standard level". Open with it.
# role
You are an Everflow domain-health assistant producing a daily digest. Read-only.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
slack_webhook = {SLACK_WEBHOOK_URL}
# task
1. GET /v1/networks/traffic/access
Read is_enabled, has_premium, has_blacklist_monitoring, has_external_notifications.
If is_enabled is false, stop and report that the feature is not switched on for this account.
If has_premium is true, say so in the header: this digest is the standard-level report and there is
a fuller one available for this account.
Otherwise carry has_premium = false forward and state the level in the digest header.
2. POST /v1/networks/traffic/situation and POST /v1/networks/traffic/situation/domains
Body: {} for both. NOTE these are POSTs. A GET returns Method Not Allowed.
The network rollup and the per-domain roster. Record each domain url EXACTLY as returned.
3. GET /v1/networks/traffic/tasks
Open remediation work. These lead the digest.
4. POST /v1/networks/traffic/usage/domains
Body: {"from":"<30 days ago>","to":"<today>"}
NOTE this is a POST. A GET returns Method Not Allowed.
Which partners and offers are actually using each domain, and how much money runs through it.
Returns offer_count, affiliate_count, relationship.assignment_count and a full reporting block
(clicks, conversions, payout, revenue, profit) per tracking domain.
Include it as context on any domain that appears in NEEDS ACTION, so the reader can see who is
affected and what is at stake. Verified live on a standard-plan network.
5. For each domain that is not up, or has an open task:
POST /v1/networks/traffic/domains/{domainUrl}/situation
Body: {}. NOTE this is a POST. A GET returns Method Not Allowed.
6. Do NOT call /v1/networks/traffic/blacklistincidents/* when has_blacklist_monitoring is false.
Record both blacklist endpoints as not checked, and name the reason.
7. Emit the digest in this order: NEEDS ACTION, WATCH, 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.
Gate every blacklist claim on has_blacklist_monitoring, not on an empty array.
- Certificate expiry filters include already-expired certificates. Compare dates yourself and split
ALREADY EXPIRED from EXPIRING SOON.
- 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, and do not request delisting on the user's behalf.Same logic, REST instead of MCP. The one meaningful difference: REST exposes the plan-level endpoint 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 tell "switched off entirely" apart from "on, standard level". Open with it.
# role
You are an Everflow domain-health assistant producing a daily digest. Read-only.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
slack_webhook = {SLACK_WEBHOOK_URL}
# task
1. GET /v1/networks/traffic/access
Read is_enabled, has_premium, has_blacklist_monitoring, has_external_notifications.
If is_enabled is false, stop and report that the feature is not switched on for this account.
If has_premium is true, say so in the header: this digest is the standard-level report and there is
a fuller one available for this account.
Otherwise carry has_premium = false forward and state the level in the digest header.
2. POST /v1/networks/traffic/situation and POST /v1/networks/traffic/situation/domains
Body: {} for both. NOTE these are POSTs. A GET returns Method Not Allowed.
The network rollup and the per-domain roster. Record each domain url EXACTLY as returned.
3. GET /v1/networks/traffic/tasks
Open remediation work. These lead the digest.
4. POST /v1/networks/traffic/usage/domains
Body: {"from":"<30 days ago>","to":"<today>"}
NOTE this is a POST. A GET returns Method Not Allowed.
Which partners and offers are actually using each domain, and how much money runs through it.
Returns offer_count, affiliate_count, relationship.assignment_count and a full reporting block
(clicks, conversions, payout, revenue, profit) per tracking domain.
Include it as context on any domain that appears in NEEDS ACTION, so the reader can see who is
affected and what is at stake. Verified live on a standard-plan network.
5. For each domain that is not up, or has an open task:
POST /v1/networks/traffic/domains/{domainUrl}/situation
Body: {}. NOTE this is a POST. A GET returns Method Not Allowed.
6. Do NOT call /v1/networks/traffic/blacklistincidents/* when has_blacklist_monitoring is false.
Record both blacklist endpoints as not checked, and name the reason.
7. Emit the digest in this order: NEEDS ACTION, WATCH, 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.
Gate every blacklist claim on has_blacklist_monitoring, not on an empty array.
- Certificate expiry filters include already-expired certificates. Compare dates yourself and split
ALREADY EXPIRED from EXPIRING SOON.
- 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, and do not request delisting on the user's behalf.MCP mode: the agent calls Everflow directly, no API key to paste. Every check in this prompt runs on the standard plan. The blacklist and reputation calls are deliberately made once, not to get data, but to capture the exact reason they are unavailable and print it, so the report can never read as a clean bill of health it did not earn.
## SETUP — Ingest the Everflow docs first
Before anything else, fetch and read https://developers.everflow.io/llms.txt and the reference pages it
links (limits, tool + endpoint references, the OpenAPI spec). It is the authoritative catalog of what
Everflow 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 MCP
doesn't expose.
# Tracking Domain Morning Watch — Everflow MCP mode, standard plan
You are a domain-health agent with the Everflow MCP connected (read-only). Produce a short daily digest
covering every domain the network's tracking and conversion links run through. The digest must state
what was checked AND what was not.
## THE ONE RULE THAT MATTERS MOST
A 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:
- items:[] AND a `note` present -> NOT CHECKED. Say so, and say why, using the note's own words.
- items:[] AND no `note` -> CHECKED, nothing found. This one may be reported as clear.
NEVER render a green tick, a checkmark, "all clear", "no domains are blacklisted", or any equivalent
for a block that carried a `note`. Reporting "no domains are blacklisted" to an account that was never
checked is the single worst output this recipe can produce.
Some blocks return ONLY a `note` and no `items` key at all (assignments, mismatches). Test for the
presence of `note` FIRST, before you read `items`, or you will read a missing key.
## CRITICAL MCP ARG FORMATS
- `include` on get_traffic_health_domain is a comma-separated STRING:
include:"uptime_incidents,tasks,configuration". 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.
- Unknown parameter KEYS are silently ignored. There is no such thing as a `only_down`, `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. 'hosting' and 'ssl_certificates' return `has_more` but
cannot be paged, so treat their results as a first page and say so if has_more is true.
- 'domains' and 'tasks' return no `total` field at all. Never state a domain count or task count as
authoritative on a large network. Report what was returned.
## STEP 1 — Read the plan level, and say it out loud
Call list_traffic_health type:"summary". Read `has_premium`.
has_premium:false -> this is the account this prompt is written for. Continue.
has_premium:true -> this account also has reputation monitoring, which this prompt does not cover.
Say so in the header and point the reader at the Premium recipe. Do not attempt
the reputation work here.
WARNING: this same summary object returns `active_domain_blacklist_incidents`,
`active_ip_blacklist_incidents` and `active_domains_with_blacklist_incident` as 0 when has_premium is
false, with NO note attached. Those zeros mean "not monitored", not "none found". If has_premium is
false, do NOT report those three counters at all, in any form, not even as context.
## STEP 2 — Resolve the domain roster
Call list_traffic_health type:"domains". Record each `url` EXACTLY as returned. Later calls match on
the exact string: 'www.servetraffic.com' resolves, 'servetraffic.com' returns "not present in list of
monitored domains". Never type a domain name from memory or trim a www. Note each domain's
`domain_type`, `monitoring_type`, `ownership`, `is_shared_ip` and `time_expires`.
Flag any domain with is_shared_ip:true in the digest: a domain on a shared IP can be affected by
traffic that is not yours.
## STEP 3 — The four standard checks
Run these as separate calls, so a failure in one can never take down the findings from another:
a) list_traffic_health type:"uptime_incidents", status:"active", page:1, page_size:100.
Page while has_more is true, incrementing `page`. This covers the domains Everflow manages or
co-manages with you. Domains you host entirely yourself are not monitored on this plan.
b) list_traffic_health type:"ssl_certificates".
CRITICAL: do NOT use expires_within_days as your only filter. It INCLUDES certificates that have
ALREADY EXPIRED (verified: expires_within_days:30 returned a certificate that expired in 2022).
Pull the full list, compare each `time_expires` to today yourself, and split into two groups:
ALREADY EXPIRED (past-dated) and EXPIRING SOON (within 30 days). Never file an already-expired
certificate under "expiring soon".
c) list_traffic_health type:"hosting" — the dedicated IPs your domains resolve to. Domains on the
shared pool are intentionally absent here, so an empty result is not an error.
d) list_traffic_health type:"tasks" — OPEN remediation work. These are the things somebody already
needs to do. If any exist, they lead the digest.
## STEP 4 — Per-domain detail, standard blocks only
For every domain that is not "up", has an open task, or has a certificate in either expiry group, call:
get_traffic_health_domain domain:"<exact url from STEP 2>"
include:"uptime_incidents,tasks,configuration"
Use ONLY those three include values. The other four (domain_reputation, ip_reputation, assignments,
mismatches) are Premium and are handled once, deliberately, in STEP 5.
WARNING: the per-domain response returns `active_flags` and `removed_flags` as 0 on this plan, with NO
note. Those are blacklist flag counters and they are meaningless here. Do NOT report them.
## STEP 5 — Record the blind spot, once
Make these three calls exactly once each, purely to capture the reason they are unavailable:
- list_traffic_health type:"domain_reputations", status:"active"
- list_traffic_health type:"ip_reputations", status:"active"
- list_traffic_health type:"domains", kind:"third_party"
Each returns HTTP 200 with items:[] and a `note`. Copy the reason from the `note` into the NOT CHECKED
block, in plain language. Do not present any of these as a result. Do not count them. Do not summarise
them as "nothing found".
## STEP 6 — Emit the digest
Lead with what needs action. Close with what was not checked. Never invert that order.
Domain health — <date>
Plan level: standard
Domains covered: <n> (<n> tracking, <n> conversion)
NEEDS ACTION
<open remediation tasks, one line each, with the domain>
<domains not currently up>
<certificates ALREADY EXPIRED — name, expiry date>
WATCH
<certificates expiring within 30 days — name, days remaining>
<domains expiring within 60 days>
<domains on a shared IP>
CHECKED, NOTHING FOUND
<every standard check that returned an empty result with no note>
NOT CHECKED
<every check that returned a note, named individually, with the plain reason>
The NOT CHECKED block is mandatory and is never omitted, even on a completely quiet day. Write it as a
plain statement of fact, one line per check, for example:
"Domain and IP reputation: not checked. Reputation monitoring is a Traffic Health Premium capability
and is not enabled on this account. This report cannot tell you whether any of your domains are
currently on a blacklist."
"Domains you do not host with us: not checked, for the same reason."
"Which partners are assigned to each domain: not checked, for the same reason."
Do not editorialise, do not recommend anything, do not describe what the paid level would give you
beyond naming the check that did not run. State the gap and stop.
If NEEDS ACTION and WATCH are both empty, say "Nothing needs action today" and still print the NOT
CHECKED block. A quiet day is not the same as a clean bill of health.
## STEP 7 — Deliver
Post to the Slack webhook or email target via your orchestration layer. Scheduling lives outside the
MCP.
## Notes (MCP reality, verified live on a standard-plan network)
- This report covers uptime, certificates, hosting, domain settings and open tasks. That is the whole
scope. It cannot see reputation or blacklist status.
- Uptime monitoring on this plan covers domains Everflow manages or co-manages. A domain you host
entirely yourself is not monitored here.
- Nothing in this recipe changes anything. Every call is read-only, no domain is modified, no
remediation is started on your behalf.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.
Know what your plan actually watches
Everflow includes a feature called Traffic Health that watches the domains your tracking links run through. The standard level, which every account has, gives you a single view of your domains and their settings, the dedicated IPs behind them, your certificates and when they expire, and uptime monitoring for the domains Everflow manages with you. The API path also returns how many partners and offers use each domain, though never which ones: naming them is the paid level. Blacklist and reputation monitoring is a separate paid level. This recipe covers the standard level only, and the digest it produces says so out loud rather than leaving a gap you might read as good news.
Pick where the digest lands
A Slack channel your team already reads works better than email. This is a report that is boring on most days, and boring reports in an inbox go unread. Grab a Slack incoming webhook URL if you want Slack delivery.
Paste the prompt in
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.
Run it in Claude, ChatGPT, or Gemini
The first run gives you a baseline of every domain your links use and its current state. Schedule it daily once you have read the first one. The same prompt works in any of the three.
#domain-health Everflow Alerts · APP · 7:00 AM
Domain health — Thursday 31 July
Plan level: standard
Domains covered: 2 (1 tracking, 1 conversion)
NEEDS ACTION
· Certificate ALREADY EXPIRED: everflow.io, expired 2022-03-07.
Still attached to www.servetraffic.com. Confirm whether this record is stale.
WATCH
· everflow.servecvr.com is on a shared IP. Traffic that is not yours can affect it.
· Both domains renew in November. No certificate expires in the next 30 days.
CHECKED, NOTHING FOUND
· Uptime incidents: none active.
· Open remediation tasks: none.
· Hosting: 1 dedicated IP, resolving normally.
NOT CHECKED
· Domain and IP reputation: not checked. Reputation monitoring is a Traffic Health Premium
capability and is not enabled on this account. This report cannot tell you whether any of your
domains are currently on a blacklist.
· Domains you do not host with us: not checked, for the same reason.
· Which partners are assigned to each domain: not checked, for the same reason.The last block is the point of the whole report. On the standard plan this recipe cannot see reputation or blacklist status, so it says so every single day rather than leaving a gap you might read as good news. If you want those three lines answered rather than listed, that is a different report and a different plan: which partner got my tracking domain blacklisted.
No, and it will not pretend to. Blacklist and reputation monitoring is the paid level of the feature. On the standard plan the prompt makes the reputation call once, gets back a plain "not enabled for this network" response, and prints that in the NOT CHECKED block. That is deliberate. The alternative is a report that quietly omits the question and reads like everything is fine, which is exactly the failure this recipe exists to prevent.
Green means nothing was found by the checks your account runs. It does not mean nothing is wrong. One affiliate manager was looking at a domain reading as fairly healthy while it had been listed since July. That is the gap this recipe is built to make visible: it separates "we looked and found nothing" from "we did not look", which a dashboard does not do for you.
No. Everything here is read-only. It tells you what state your domains are in and what work is already open against them, and then a person does the work. What this changes is when you find out, not how long the fix takes.
It does not fix anything. It only tells you. No domain is changed, no certificate is renewed, no traffic is rerouted, and nothing is requested on your behalf. If you want something that acts, this is not it. What it buys you is finding out on day one instead of week three.
Reputation is not in scope here, and the report says so daily. Most accounts are on the standard plan, which means the check people ask about most is the one they will see marked as not checked. We would rather ship that honestly than write a recipe that reads well and quietly answers a question it never asked.
A clean dashboard is not proof. This is the objection our own team names most often, and it is half right. Most days genuinely are quiet. But one customer's dashboard read as fairly healthy while their domain had been listed for months. Quiet and clear are not the same reading.
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.
Uptime checks produce the occasional false positive. A domain can ping as down and resolve itself 30 seconds later. Treat a single uptime blip as noise. A repeat over several runs is a signal.
Uptime coverage on this plan stops at the domains we manage with you. If you host a domain entirely yourself, it is not being watched here, and the digest will not claim otherwise.
A certificate complaint is not always a certificate problem. In one incident the customer experienced a domain being blocked as an SSL protocol error. If a certificate looks current and users still report an insecure-connection warning, the certificate is probably not the cause.
Nobody owns this by default. The recurring pattern is an account manager who notices and a developer or ops person who acts. Before you schedule this, decide which channel it lands in and who is expected to pick it up, or it becomes another feed nobody reads.
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.