Spot risks early
Know which affiliates will hit their payout cap before they do. A daily ranked digest with projected trip dates, straight to Slack.
.svg)
Medium
.svg)
Pulls current-period payout and cap settings for every active affiliate, computes how close each one is to their limit, and drops the alert in Slack or your inbox before any cap trips. Set your own threshold (80% is the default). Runs in under 2 minutes, or on an automatic daily schedule so you never find out after the fact.
Caps exist for a reason. The question is whether you find out before or after the partner does. Everflow already ships cap controls: per-offer daily / weekly / monthly / global caps across conversion / payout / revenue / click, threshold alerts at user-defined percentages, auto-deactivation at 100%, auto-redirect to a fallback offer, and a pacing report. If you set it up, native does its job.
What native doesn't do is the cross-program ranked daily push. Per-cap alerts fire one offer at a time. Nothing surfaces "Across your whole program, here are the five partners closest to their cap right now, sorted by urgency, with projected trip dates" in one Slack message before standup. The pacing report exists but it's on-demand. You have to log in and pull it. The recipe runs that scan every morning, ranks the partners, projects who trips when, and drops the digest in Slack so you can act before the partner notices.
The wow moment is the 8 AM Slack ping with three rows ranked by how close they are. The pain it solves is the manual cross-program scan no one remembers to run.
All I have is just a note from my team that we need to be integrated with Slack. Probably some alerts which can be sent in a specific Slack channel about some issues. For example, this offer has reached its cap.
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. Default threshold is 80%; swap to any value between 0.0 and 1.0.
## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are an Everflow affiliate operations assistant.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
timezone_id = {TIMEZONE_ID} # your network's reporting timezone
currency_id = {CURRENCY_ID} # e.g. USD
alert_threshold = {ALERT_THRESHOLD} # default 0.80 (80%). Change to 0.70, 0.90, etc.
# task
1. Read the caps that are actually configured. Caps in Everflow are OFFER-scoped, not
affiliate-scoped, and they are NOT fields on the affiliate object.
POST /v1/networks/reporting/caps/offer
body: {
timezone_id: {TIMEZONE_ID},
currency_id: "{CURRENCY_ID}",
from: "{first day of current cap window}",
to: "{today}"
}
→ { caps: [ ... ], paging: { page, page_size, total_count } }
Also read the custom cap settings, which hold caps configured outside the standard set:
POST /v1/networks/custom/capstable
body: {}
→ { custom_cap_settings: [ ... ], paging: { page, page_size, total_count } }
Paginate both with page / page_size until you have total_count rows.
2. 🛑 STOP AND BRANCH HERE. This is the step that decides whether the report means anything.
If BOTH responses come back empty (caps: [] and custom_cap_settings: []), then this network
has NO CAPS CONFIGURED. Say exactly that and stop:
"No caps are configured on this network, so there is nothing to monitor. This is not the
same as every partner being safely under cap — nothing was measured."
Do NOT report "all clear." An empty caps list means the question was never asked.
Only continue to step 3 if at least one cap came back.
3. Pull period-to-date spend for the capped entities.
POST /v1/networks/reporting/entity/table
body: {
columns: [{ column: "offer" }],
query: { filters: [], exclusions: [] },
from: "{first day of current cap window}",
to: "{today}"
}
NOTE: do NOT send sort_columns. It is silently ignored on this endpoint — verified
against the live API; payout-descending and no-sort return identical row order, and
the server's first rows were all zero-payout while the true top rows shared none of
those names. Sort the rows yourself, in your own code, AFTER the fetch. Metrics live
under `reporting` on each row (reporting.payout, reporting.cv, reporting.revenue);
the entity name is columns[0].label. There is no top-level payout field.
4. Join spend to caps on the offer id, then compute per capped entity:
cap_used_pct = period_spend / cap_amount
remaining = cap_amount - period_spend
5. Filter to entities where cap_used_pct >= alert_threshold.
6. Sort by cap_used_pct descending (most urgent first).
7. Format a digest with: headline, per-entity row (name + ID, cap used, remaining, pace flag),
and a footer link to Everflow reporting. Return it as Markdown.
# guardrails
- 🛑 NEVER print "all clear" off an empty caps list. Empty means no caps are configured; say that.
Distinguish "nothing is near its cap" (measured) from "nothing is capped" (not measured).
- Do NOT read payout_cap, daily_payout_cap or cap_type from GET /v1/networks/affiliates/{id}.
That object does not contain them. It returns account_status, name, network_affiliate_id,
default_currency_id, relationship and similar — no cap fields at all, so any recipe that
reads caps from it silently skips every partner.
- Pace flag: (period_spend / days_elapsed) * days_remaining. If projected > cap, flag "AT RISK."
- Round currency to whole dollars; percentages to 1 decimal.
- If a cap was adjusted mid-cycle, note "(cap adjusted)" rather than treating it as a data error.
- This recipe reads only. It never writes.
# What you must disclose — NOT CHECKED
An empty result is NOT a clean result. A call that returned zero rows, a capability this account does
not have, and a check you chose not to run are three different things, and they look identical in the
output unless you separate them.
End every run with a NOT CHECKED block. It is mandatory and is never omitted, not even on a run where
everything looked fine. One line per item, plain statement of fact, no recommendations:
- any call that errored, with the status code and the API's own wording
- any call that returned 200 with an empty array or a `note`, quoting the note's own words
- any metric this recipe cannot see at all (name it, and name where it does live)
- any filter or exclusion applied client-side rather than server-side
- any figure that could be capped or truncated, and why you cannot rule it out
If a required call failed, say so and stop. Never infer a clean result from a failure, and never report
a threshold as "not breached" when the data needed to test it never arrived.## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are an Everflow affiliate operations assistant.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
timezone_id = {TIMEZONE_ID} # your network's reporting timezone
currency_id = {CURRENCY_ID} # e.g. USD
alert_threshold = {ALERT_THRESHOLD} # default 0.80 (80%). Change to 0.70, 0.90, etc.
# task
1. Read the caps that are actually configured. Caps in Everflow are OFFER-scoped, not
affiliate-scoped, and they are NOT fields on the affiliate object.
POST /v1/networks/reporting/caps/offer
body: {
timezone_id: {TIMEZONE_ID},
currency_id: "{CURRENCY_ID}",
from: "{first day of current cap window}",
to: "{today}"
}
→ { caps: [ ... ], paging: { page, page_size, total_count } }
Also read the custom cap settings, which hold caps configured outside the standard set:
POST /v1/networks/custom/capstable
body: {}
→ { custom_cap_settings: [ ... ], paging: { page, page_size, total_count } }
Paginate both with page / page_size until you have total_count rows.
2. 🛑 STOP AND BRANCH HERE. This is the step that decides whether the report means anything.
If BOTH responses come back empty (caps: [] and custom_cap_settings: []), then this network
has NO CAPS CONFIGURED. Say exactly that and stop:
"No caps are configured on this network, so there is nothing to monitor. This is not the
same as every partner being safely under cap — nothing was measured."
Do NOT report "all clear." An empty caps list means the question was never asked.
Only continue to step 3 if at least one cap came back.
3. Pull period-to-date spend for the capped entities.
POST /v1/networks/reporting/entity/table
body: {
columns: [{ column: "offer" }],
query: { filters: [], exclusions: [] },
from: "{first day of current cap window}",
to: "{today}"
}
NOTE: do NOT send sort_columns. It is silently ignored on this endpoint — verified
against the live API; payout-descending and no-sort return identical row order, and
the server's first rows were all zero-payout while the true top rows shared none of
those names. Sort the rows yourself, in your own code, AFTER the fetch. Metrics live
under `reporting` on each row (reporting.payout, reporting.cv, reporting.revenue);
the entity name is columns[0].label. There is no top-level payout field.
4. Join spend to caps on the offer id, then compute per capped entity:
cap_used_pct = period_spend / cap_amount
remaining = cap_amount - period_spend
5. Filter to entities where cap_used_pct >= alert_threshold.
6. Sort by cap_used_pct descending (most urgent first).
7. Format a digest with: headline, per-entity row (name + ID, cap used, remaining, pace flag),
and a footer link to Everflow reporting. Return it as Markdown.
# guardrails
- 🛑 NEVER print "all clear" off an empty caps list. Empty means no caps are configured; say that.
Distinguish "nothing is near its cap" (measured) from "nothing is capped" (not measured).
- Do NOT read payout_cap, daily_payout_cap or cap_type from GET /v1/networks/affiliates/{id}.
That object does not contain them. It returns account_status, name, network_affiliate_id,
default_currency_id, relationship and similar — no cap fields at all, so any recipe that
reads caps from it silently skips every partner.
- Pace flag: (period_spend / days_elapsed) * days_remaining. If projected > cap, flag "AT RISK."
- Round currency to whole dollars; percentages to 1 decimal.
- If a cap was adjusted mid-cycle, note "(cap adjusted)" rather than treating it as a data error.
- This recipe reads only. It never writes.
# What you must disclose — NOT CHECKED
An empty result is NOT a clean result. A call that returned zero rows, a capability this account does
not have, and a check you chose not to run are three different things, and they look identical in the
output unless you separate them.
End every run with a NOT CHECKED block. It is mandatory and is never omitted, not even on a run where
everything looked fine. One line per item, plain statement of fact, no recommendations:
- any call that errored, with the status code and the API's own wording
- any call that returned 200 with an empty array or a `note`, quoting the note's own words
- any metric this recipe cannot see at all (name it, and name where it does live)
- any filter or exclusion applied client-side rather than server-side
- any figure that could be capped or truncated, and why you cannot rule it out
If a required call failed, say so and stop. Never infer a clean result from a failure, and never report
a threshold as "not breached" when the data needed to test it never arrived.## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are an Everflow affiliate operations assistant.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
timezone_id = {TIMEZONE_ID} # your network's reporting timezone
currency_id = {CURRENCY_ID} # e.g. USD
alert_threshold = {ALERT_THRESHOLD} # default 0.80 (80%). Change to 0.70, 0.90, etc.
# task
1. Read the caps that are actually configured. Caps in Everflow are OFFER-scoped, not
affiliate-scoped, and they are NOT fields on the affiliate object.
POST /v1/networks/reporting/caps/offer
body: {
timezone_id: {TIMEZONE_ID},
currency_id: "{CURRENCY_ID}",
from: "{first day of current cap window}",
to: "{today}"
}
→ { caps: [ ... ], paging: { page, page_size, total_count } }
Also read the custom cap settings, which hold caps configured outside the standard set:
POST /v1/networks/custom/capstable
body: {}
→ { custom_cap_settings: [ ... ], paging: { page, page_size, total_count } }
Paginate both with page / page_size until you have total_count rows.
2. 🛑 STOP AND BRANCH HERE. This is the step that decides whether the report means anything.
If BOTH responses come back empty (caps: [] and custom_cap_settings: []), then this network
has NO CAPS CONFIGURED. Say exactly that and stop:
"No caps are configured on this network, so there is nothing to monitor. This is not the
same as every partner being safely under cap — nothing was measured."
Do NOT report "all clear." An empty caps list means the question was never asked.
Only continue to step 3 if at least one cap came back.
3. Pull period-to-date spend for the capped entities.
POST /v1/networks/reporting/entity/table
body: {
columns: [{ column: "offer" }],
query: { filters: [], exclusions: [] },
from: "{first day of current cap window}",
to: "{today}"
}
NOTE: do NOT send sort_columns. It is silently ignored on this endpoint — verified
against the live API; payout-descending and no-sort return identical row order, and
the server's first rows were all zero-payout while the true top rows shared none of
those names. Sort the rows yourself, in your own code, AFTER the fetch. Metrics live
under `reporting` on each row (reporting.payout, reporting.cv, reporting.revenue);
the entity name is columns[0].label. There is no top-level payout field.
4. Join spend to caps on the offer id, then compute per capped entity:
cap_used_pct = period_spend / cap_amount
remaining = cap_amount - period_spend
5. Filter to entities where cap_used_pct >= alert_threshold.
6. Sort by cap_used_pct descending (most urgent first).
7. Format a digest with: headline, per-entity row (name + ID, cap used, remaining, pace flag),
and a footer link to Everflow reporting. Return it as Markdown.
# guardrails
- 🛑 NEVER print "all clear" off an empty caps list. Empty means no caps are configured; say that.
Distinguish "nothing is near its cap" (measured) from "nothing is capped" (not measured).
- Do NOT read payout_cap, daily_payout_cap or cap_type from GET /v1/networks/affiliates/{id}.
That object does not contain them. It returns account_status, name, network_affiliate_id,
default_currency_id, relationship and similar — no cap fields at all, so any recipe that
reads caps from it silently skips every partner.
- Pace flag: (period_spend / days_elapsed) * days_remaining. If projected > cap, flag "AT RISK."
- Round currency to whole dollars; percentages to 1 decimal.
- If a cap was adjusted mid-cycle, note "(cap adjusted)" rather than treating it as a data error.
- This recipe reads only. It never writes.
# What you must disclose — NOT CHECKED
An empty result is NOT a clean result. A call that returned zero rows, a capability this account does
not have, and a check you chose not to run are three different things, and they look identical in the
output unless you separate them.
End every run with a NOT CHECKED block. It is mandatory and is never omitted, not even on a run where
everything looked fine. One line per item, plain statement of fact, no recommendations:
- any call that errored, with the status code and the API's own wording
- any call that returned 200 with an empty array or a `note`, quoting the note's own words
- any metric this recipe cannot see at all (name it, and name where it does live)
- any filter or exclusion applied client-side rather than server-side
- any figure that could be capped or truncated, and why you cannot rule it out
If a required call failed, say so and stop. Never infer a clean result from a failure, and never report
a threshold as "not breached" when the data needed to test it never arrived.MCP mode: the agent calls Everflow directly, no API key to paste. (MCP is a connector that lets your AI tool talk to Everflow on its own.) You supply each partner's cap value; the MCP reads payout so far this period and how fast it's pacing, since the cap setting itself lives in partner/offer config the reporting tools don't read.
## 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 (e.g. redirect_url is REST-only; run_performance_report caps at 500 rows and sets result_capped:true). Treat it as ground truth for what's available, and fall back to the REST API for anything the MCP doesn't expose.
You are a partnerships/performance manager for an Everflow network with a read-only Everflow MCP connected (tools: run_performance_report, run_network_summary, get_offer, list_offers, get_affiliate, list_affiliates, get_report_schema, search_activity, etc.). Everflow does NOT reliably expose payout-cap CONFIG through the API/MCP (get_affiliate returns no cap fields; get_offer include=caps returns numeric limits only when caps are actually enabled on the offer, otherwise just caps_enabled=false), so the cap thresholds are supplied by YOU below. Your job: flag which offers/partners are approaching their payout cap for the current period BEFORE they trip it, and return a ranked digest with utilization percent, dollars remaining, and a burn-rate AT RISK pace projection.
===== USER-SUPPLIED INPUTS (edit these — do not skip) =====
- CAP_PERIOD_START: {first day of the current cap window, YYYY-MM-DD}
- CAP_PERIOD_END: {last day of the cap window, YYYY-MM-DD}
- AS_OF: {today's date, YYYY-MM-DD} (must be within the window)
- ALERT_THRESHOLD: 80 (percent; flag entities at/above this percent of cap)
- CAP_LEVEL: offer (offer or affiliate — the entity the caps apply to)
- CAPS: a small table you maintain of each capped entity's payout cap for THIS period.
Format = id | name | payout_cap_usd. Example rows:
101 | Summer Push Offer | 5000
102 | Homepage Signups | 2000
103 | Newsletter CTA | 12000
(If you cap at the affiliate level, set CAP_LEVEL=affiliate and list affiliate_ids.)
If you leave CAPS empty, do Step 1b to auto-discover offers that have caps enabled, then ask me to fill in the numbers.
===== ARG-FORMAT RULES (the MCP silently misbehaves otherwise) =====
- dimensions and metrics MUST be a single COMMA-SEPARATED STRING (e.g. affiliate,date), NOT a JSON array. An array returns INVALID_ARGUMENT.
- run_performance_report filters is a comma-separated type:value STRING (e.g. offer:7|23|41); use the pipe | for OR within one type.
- Paginate: run_performance_report caps at page_size 100 and about 500 rows total. Pass page_size:100, then re-call with cursor set to the previous response next_cursor until has_more is false (note result_capped if returned true).
- Dates are YYYY-MM-DD.
===== STEP 1 — Period-to-date payout per capped entity (this WORKS) =====
Call run_performance_report with:
from = CAP_PERIOD_START
to = AS_OF
dimensions = offer if CAP_LEVEL is offer, else affiliate
metrics = payout,revenue,conversions,invalid_clicks
filters = capped ids joined by pipe, e.g. offer:7|23|41 (or omit filters to pull all, then match by id to your CAPS table)
page_size = 100
Paginate with cursor/next_cursor until has_more=false. Collect payout, revenue, conversions, invalid_clicks per entity.
The payout field is the real per-entity payout for the window; that is your cap NUMERATOR.
invalid_clicks = clicks rejected by validation (geo, CAP, fraud). A non-zero / rising invalid_clicks on a high-utilization entity corroborates that its cap is ALREADY throttling — surface it, do not compute with it.
STEP 1b (only if CAPS is empty) — auto-find capped offers:
For each active offer (list_offers, paginate via next_cursor), call get_offer(offer_id, include=caps). Keep only offers whose caps object shows caps_enabled=true AND returns a numeric payout/revenue limit. Report those ids+limits back to me and STOP — I will paste them into CAPS and re-run. Where caps are disabled you get caps_enabled=false with no number; those cannot be auto-monitored, supply the cap in CAPS.
===== STEP 2 — Utilization percent and dollars remaining =====
For each entity present in CAPS:
cap_used_pct = round(100 * payout_to_date / payout_cap_usd, 1)
dollars_left = round(payout_cap_usd - payout_to_date, 2)
Skip entities with payout_to_date == 0 (nothing to alert) UNLESS invalid_clicks is high (possible cap already hard-blocking — list separately under Check config).
===== STEP 3 — Burn-rate pace projection (the AT RISK flag) =====
One more report for the daily curve:
Call run_performance_report with:
from = CAP_PERIOD_START
to = AS_OF
dimensions = offer,date if CAP_LEVEL is offer, else affiliate,date
metrics = payout
filters = same pipe-joined ids
page_size = 100 (paginate via cursor — daily times entity rows add up fast)
For each entity:
days_elapsed = AS_OF - CAP_PERIOD_START + 1
days_in_period = CAP_PERIOD_END - CAP_PERIOD_START + 1
avg_daily = payout_to_date / days_elapsed
projected_end = payout_to_date + avg_daily * (days_in_period - days_elapsed)
projected_pct = round(100 * projected_end / payout_cap_usd, 1)
Flag AT RISK if projected_pct >= 100 (on pace to blow the cap before period end), even if cap_used_pct is under threshold today. Optionally use the last-3-days daily payout instead of the whole-window average if traffic is accelerating (note which basis you used).
===== STEP 4 — Rank + filter =====
Keep entities where cap_used_pct >= ALERT_THRESHOLD OR projected_pct >= 100. Sort by cap_used_pct descending; pin AT RISK pace items near the top.
===== STEP 5 — Output digest (Markdown, ready to paste into Slack/email) =====
Return exactly this shape:
:rotating_light: Cap Alert — CAP_LEVEL entities at/above ALERT_THRESHOLD percent of payout cap
Period CAP_PERIOD_START to CAP_PERIOD_END · as of AS_OF · day days_elapsed/days_in_period
For each qualifying entity, one row:
• NAME (id ID) — CAP_USED_PCT percent used · $PAYOUT_TO_DATE of $PAYOUT_CAP_USD · $DOLLARS_LEFT left
pace to projected PROJECTED_PCT percent by CAP_PERIOD_END [AT RISK — on pace to exceed cap, if projected_pct>=100, else on track]
[sub-line only if invalid_clicks>0: INVALID_CLICKS clicks already rejected by validation (possible cap throttling)]
Footer:
N of TOTAL_CAPPED monitored CAP_LEVEL entities over threshold. Caps are manager-supplied (Everflow does not expose cap config via API). Verify limits in the Everflow UI: Offers, then the offer, then Caps.
If nothing is over threshold and nothing is AT RISK, say so plainly (All TOTAL_CAPPED monitored entities are pacing under ALERT_THRESHOLD percent; highest is NAME at X percent.).
===== DELIVERY + CAVEATS =====
The Everflow MCP is read-only and cannot POST to a Slack webhook. Return the digest as Markdown for me to paste, OR if you also have a Slack/webhook MCP or tool connected, hand the Markdown to that tool. Do not attempt to post via Everflow.
CAP CONFIG CAVEAT: Everflow does not expose payout-cap config via the API/MCP, so you supply the cap values above; the recipe reads only actual period-to-date payout against them. If payout comes back $0 for every capped entity, cap_used_pct is 0.0 and nothing alerts — point this at a network with real payout to see live utilization.
# What you must disclose — NOT CHECKED
An empty result is NOT a clean result. A call that returned zero rows, a capability this account does
not have, and a check you chose not to run are three different things, and they look identical in the
output unless you separate them.
End every run with a NOT CHECKED block. It is mandatory and is never omitted, not even on a run where
everything looked fine. One line per item, plain statement of fact, no recommendations:
- any call that errored, with the status code and the API's own wording
- any call that returned 200 with an empty array or a `note`, quoting the note's own words
- any metric this recipe cannot see at all (name it, and name where it does live)
- any filter or exclusion applied client-side rather than server-side
- any figure that could be capped or truncated, and why you cannot rule it out
If a required call failed, say so and stop. Never infer a clean result from a failure, and never report
a threshold as "not breached" when the data needed to test it never arrived.
- whether meta.result_capped was true on any run_performance_report call. It caps at 500 rows
(meta.row_limit) while meta.total_rows reports the real figure, so a truncated report looks
complete unless you compare the two. State both numbers.Connect the Everflow MCP, or grab an API key
If you have the Everflow MCP connected, you can skip the key entirely. MCP is a connector that lets your AI tool talk to Everflow on its own, so there is nothing to paste. No MCP yet? Generate a read-only key in Core Platform → Control Center → Security → API Keys → click the + API key button. Read-only on Reporting is enough.
Set your alert threshold
Default is 80%: you'll get flagged on any affiliate who has used 80% or more of their current-period cap. Lower it to 70% for earlier warnings; raise it to 90% if you prefer tighter alerts.
Decide your notification channel
The prompt sends a Slack digest by default. Swap in an email address if you'd rather get it in your inbox.
Run the prompt
With MCP connected, just run the prompt as written. On the API tab, first replace {API_KEY}, {NETWORK_ID}, {ALERT_THRESHOLD} (default 0.80), and {SLACK_WEBHOOK_URL}, then run it.
Schedule it daily
Drop the prompt into Make, Zapier, or Google Apps Script and schedule it for 8 AM daily, so your team starts every day knowing where caps stand. Cap proximity moves fastest in the last week of a billing cycle, and a daily cadence catches that window.
80% is the standard starting point. It gives you roughly a week of lead time in a typical billing cycle, depending on your affiliate's send pace. If you run a high-volume program where partners can move from 80% to 100% in 48 hours, drop to 70%. If you prefer fewer alerts on slower partners, raise to 90%.
The prompt calculates each flagged affiliate's current daily average payout and projects it forward to the end of the billing cycle. If the projection exceeds the cap, they're flagged "AT RISK." If they're on track to finish under cap, it shows "On track." It's the difference between a partner at 85% who will coast to 92% by cycle end and a partner at 85% who will hit 100% in two days.
Caps in Everflow are configured on offers, and the cap window is whatever you set on the cap itself — daily, weekly or monthly. Point the recipe at that window using the from and to values on the caps call. There is no separate daily-cap field on the partner record to read, so a daily cap is checked the same way as any other: pull the caps that are actually configured, then compare spend for that window.
Native cap features acknowledged. Per-threshold alerts (50/75/90/100%), auto-deactivation, auto-redirect to fallback offer, in-platform pacing report, and partner-side notifications all exist today. The recipe doesn't replace any of them; it complements them with a cross-program ranked daily digest.
Pace-flag math is net-new. Native pacing shows current consumption. The recipe projects: "At this rate, partner X trips the weekly cap on Thursday." That projection (current pace × days remaining vs cap headroom) is the recipe's calculation, not a native feature.
What this recipe is NOT for: per-affiliate caps you've already wired native alerts on. If you have a Slack notification firing from Everflow native at 75% on Partner Y / Offer Z, you don't need the recipe to repeat it. The recipe earns its keep on programs with 20+ partners where setting up per-cap alerts for every combination isn't realistic.
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.
