How quickly does each of my top partners pay back? Which ones generate profit within 30 days and which ones need longer?

Paste this prompt into Claude. Replace {API_KEY}, {NETWORK_ID}, and {TOP_N} with your values.

## 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 financial analyst.

# inputs
api_key       = {API_KEY}

   NOTE: do NOT send a server-side sort. It is silently ignored on this endpoint -
   verified live, a descending sort and no sort return identical row order, and the
   server's first rows were all zero while the true top rows shared none of those
   names. Sort the rows yourself AFTER the fetch. Metrics live under `reporting`
   (reporting.cv, reporting.payout); the partner name is columns[0].label.
network_id    = {NETWORK_ID}
top_n         = {TOP_N}            # default 5
window_days   = 90                 # last 90 days for stable signal
currency      = USD

# task
1. Compute date range:
     to   = today (YYYY-MM-DD)
     from = today - {window_days} days

2. GET /v1/networks/affiliates
     Pull the full affiliate list. For each affiliate, capture:
     - affiliate_id, affiliate_name
     - billing_frequency (payment terms: net 7 / net 14 / net 30 / net 60 / custom)
     - status (active only)

3. POST /v1/networks/reporting/entity/table
     body: {
       from: "{from}", to: "{to}",
       columns: [{ column: "affiliate" }],
       query: { filters: [], exclusions: [] },
timezone_id: 80,
       currency_id: "{currency}"
     }
     Sort the rows yourself by reporting.cv descending, THEN take the top {top_n}. (There is no total_conversions field; the conversion count is `cv`.) Taking the first {top_n} rows as returned gives the wrong partners.

4. For each top partner, POST /v1/networks/reporting/conversions?page=1&page_size=1000
      The body MUST carry from, to, timezone_id, currency_id, show_conversions: true,
      show_events (true if you need event rows), and query.filters. Omitting
      show_conversions returns 400 "Invalid parameters".
      PAGING IS QUERY-STRING ONLY. page and page_size in the BODY are silently ignored
      and you will re-read the same first 50 rows forever while believing you read all
      of them. Read paging.total_count and loop until you have collected it.
      Do NOT filter conversion status server-side: verified against the live API, a
      status=rejected filter returned 6 rows from a window sampling 54% rejected. Each
      row carries its own status and is_scrub - filter after fetch and say that you did.
     Pull conversion detail with timestamps and payout amounts.
     For each conversion, capture:
     - conversion_unix_timestamp
     - payout
     - sale_amount

5. Calculate per partner:
     a. Total conversions, total payout, total revenue, net margin
     b. Average days from conversion to scheduled payout (use billing_frequency)
     c. Profitable within 30 days? = YES if cumulative revenue at day 30 > cumulative payout at day 30
     d. Estimated break-even day

6. Build a partner payback table sorted by break-even day (fastest first):
     Columns: Rank | Partner | Conversions | Revenue | Payout | Margin | Payment Terms | Est. Break-Even | 30-Day Profitable? | Recommended Action

     Recommended Action logic:
     - Break-even < 14d: "Strong candidate for accelerated terms (net 7 / weekly)"
     - Break-even 14-30d: "Profitable inside net 30. Current terms appropriate."
     - Break-even 31-60d: "Review: volume may justify faster terms despite longer payback"
     - Break-even > 60d: "Evaluate: high-value but slow payback. Confirm quality before adjusting."

7. Summary: how many profitable inside 30d, total cash tied up in >30d partners, one-line recommendation.

# guardrails
- Exclude test partners (affiliate_id = 1 or flagged as internal/test)
- Round currency to whole dollars
- If fewer than 10 conversions in window, flag "insufficient data"
- For subscription/recurring models: add footnote if average sale_amount suggests recurring billing
- If billing_frequency missing, default to net 30 and flag it
- Use 90-day window minimum for stable signal

Paste this prompt into Claude. Replace {API_KEY}, {NETWORK_ID}, and {TOP_N} with your values.

## 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 financial analyst.

# inputs
api_key       = {API_KEY}

   NOTE: do NOT send a server-side sort. It is silently ignored on this endpoint -
   verified live, a descending sort and no sort return identical row order, and the
   server's first rows were all zero while the true top rows shared none of those
   names. Sort the rows yourself AFTER the fetch. Metrics live under `reporting`
   (reporting.cv, reporting.payout); the partner name is columns[0].label.
network_id    = {NETWORK_ID}
top_n         = {TOP_N}            # default 5
window_days   = 90                 # last 90 days for stable signal
currency      = USD

# task
1. Compute date range:
     to   = today (YYYY-MM-DD)
     from = today - {window_days} days

2. GET /v1/networks/affiliates
     Pull the full affiliate list. For each affiliate, capture:
     - affiliate_id, affiliate_name
     - billing_frequency (payment terms: net 7 / net 14 / net 30 / net 60 / custom)
     - status (active only)

3. POST /v1/networks/reporting/entity/table
     body: {
       from: "{from}", to: "{to}",
       columns: [{ column: "affiliate" }],
       query: { filters: [], exclusions: [] },
timezone_id: 80,
       currency_id: "{currency}"
     }
     Sort the rows yourself by reporting.cv descending, THEN take the top {top_n}. (There is no total_conversions field; the conversion count is `cv`.) Taking the first {top_n} rows as returned gives the wrong partners.

4. For each top partner, POST /v1/networks/reporting/conversions?page=1&page_size=1000
      The body MUST carry from, to, timezone_id, currency_id, show_conversions: true,
      show_events (true if you need event rows), and query.filters. Omitting
      show_conversions returns 400 "Invalid parameters".
      PAGING IS QUERY-STRING ONLY. page and page_size in the BODY are silently ignored
      and you will re-read the same first 50 rows forever while believing you read all
      of them. Read paging.total_count and loop until you have collected it.
      Do NOT filter conversion status server-side: verified against the live API, a
      status=rejected filter returned 6 rows from a window sampling 54% rejected. Each
      row carries its own status and is_scrub - filter after fetch and say that you did.
     Pull conversion detail with timestamps and payout amounts.
     For each conversion, capture:
     - conversion_unix_timestamp
     - payout
     - sale_amount

5. Calculate per partner:
     a. Total conversions, total payout, total revenue, net margin
     b. Average days from conversion to scheduled payout (use billing_frequency)
     c. Profitable within 30 days? = YES if cumulative revenue at day 30 > cumulative payout at day 30
     d. Estimated break-even day

6. Build a partner payback table sorted by break-even day (fastest first):
     Columns: Rank | Partner | Conversions | Revenue | Payout | Margin | Payment Terms | Est. Break-Even | 30-Day Profitable? | Recommended Action

     Recommended Action logic:
     - Break-even < 14d: "Strong candidate for accelerated terms (net 7 / weekly)"
     - Break-even 14-30d: "Profitable inside net 30. Current terms appropriate."
     - Break-even 31-60d: "Review: volume may justify faster terms despite longer payback"
     - Break-even > 60d: "Evaluate: high-value but slow payback. Confirm quality before adjusting."

7. Summary: how many profitable inside 30d, total cash tied up in >30d partners, one-line recommendation.

# guardrails
- Exclude test partners (affiliate_id = 1 or flagged as internal/test)
- Round currency to whole dollars
- If fewer than 10 conversions in window, flag "insufficient data"
- For subscription/recurring models: add footnote if average sale_amount suggests recurring billing
- If billing_frequency missing, default to net 30 and flag it
- Use 90-day window minimum for stable signal

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.) The MCP pulls each partner's payout, revenue, and margin so the agent can estimate how fast revenue pays back what you pay them; it has no payout-settlement dates or payment terms, so terms are user-supplied and break-even is a steady-revenue proxy.

## 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 an analyst with the Everflow MCP server connected (read-only). Produce a "Payback Period by Partner" digest: rank a network's top partners by what you pay them, then show which ones the revenue they drive actually pays back, and recommend a payment-terms action for each.

IMPORTANT — this recipe runs entirely through Everflow MCP tools. Use the MCP tool names and argument formats below verbatim. Do NOT call REST endpoints. Two formatting rules the MCP enforces (violations return INVALID_ARGUMENT or silently return everything):
- `dimensions`, `metrics`, `sort_by` are COMMA-SEPARATED STRINGS, never JSON arrays. Example: dimensions:"affiliate", metrics:"payout,revenue,profit,margin,conversions".
- Reporting `filters` is a comma-separated `type:value` STRING (pipe = OR, e.g. "affiliate:123|456"); `metric_filters` is a numeric-condition STRING (e.g. "payout>0"). For list_affiliates, pass each filter as its own top-level argument (search/status/manager_id/label/tier), not nested.

===========================
USER-SUPPLIED INPUTS (fill these in before running)
===========================
- WINDOW: last 90 days. Compute FROM = today − 90 days, TO = today, both YYYY-MM-DD. (Adjust if you want a different window.)
- TOP_N: 5 (how many partners to rank).
- CURRENCY: your network default (USD unless you set otherwise).
- PAYMENT TERMS PER PARTNER (net days): The Everflow MCP does NOT expose a partner's billing frequency / payment terms as a readable field — it is filter-only, not returned. So terms are a USER INPUT. Supply a map like {Partner A: 30, Partner B: 60} for the partners that surface in Step 3. Any partner you don't specify defaults to an ASSUMED net-30, and the digest will label it "ASSUMED" so you never mistake a guess for data.

===========================
STEP 0 — Confirm the network
===========================
Call `get_account_info` to confirm which network, its default currency, and timezone. Echo them back so the reader knows the scope. (If you manage multiple networks, this is the one the connection is scoped to.)

===========================
STEP 1 — Rank partners by payout (one call, paginated)
===========================
Call `run_performance_report` with:
  from: FROM
  to: TO
  dimensions: "affiliate"
  metrics: "payout,revenue,profit,margin,conversions,total_conversions"
  sort_by: "payout"
  sort_direction: "desc"
  page_size: 100
Then PAGINATE: if the response has `next_cursor` and `has_more`/not `result_capped`, call again with the same arguments plus `cursor: <next_cursor>`, until there is no next_cursor. Note the MCP hard caps performance reports at 100 rows/page and 500 rows total (a `result_capped: true` flag means you hit the 500 ceiling — that's fine, the top-payout partners are already at the top since we sorted by payout desc). Keep the first TOP_N rows for the digest; keep the full set to compute network totals.

Metric meaning (from the report schema): `margin` is a PERCENT (2.84 = 2.84%). `payout` = what you pay the partner. `revenue` = what the partner drove for you. `profit` = revenue − payout.

===========================
STEP 2 — (Optional) enrich partner names / status
===========================
For each of the TOP_N affiliate_ids, you MAY call `get_affiliate` with affiliate_id:<id> to get name, status, manager_name, and currency. Note what it does NOT return: no billing frequency, no payment terms, no partner creation date / tenure, no payout-settlement dates. Do not attempt to read terms or "days to pay" from here — they aren't there. (`list_affiliates` with search/status/label filters is the tool if you need to look a partner up by name.)

===========================
STEP 3 — Compute payback per partner (client-side math on Step 1 numbers)
===========================
The MCP has NO per-conversion payout-settlement date, so "average days from conversion to cash" is not modelable. Instead compute a payback PROXY from the aggregate window metrics you already have. Let WINDOW_DAYS = (TO − FROM) in days.
For each of the TOP_N partners:
  - coverage_ratio = revenue / payout        (how many times the revenue covers what you paid; needs payout > 0)
  - avg_daily_revenue = revenue / WINDOW_DAYS
  - payback_days = payout / avg_daily_revenue (≈ calendar days for cumulative revenue to equal payout, assuming steady daily revenue) — this is the "Break-Even" proxy
  - terms_days = user-supplied net terms for this partner, else 30 (label "ASSUMED")
  - cash_lag_days = payback_days + terms_days (revenue must first cover payout, then your own settlement/terms delay lands the cash)
  - 30d_profitable = (profit > 0) AND (payback_days ≤ 30)
GUARDRAIL — undefined-payback check: if a partner has payout = 0 OR revenue = 0, payback is undefined for that partner; print "n/a (payout/revenue not both present)" in Break-Even and skip the 30d verdict. If, across ALL returned partners, NO partner has BOTH payout > 0 AND revenue > 0, STOP and tell the reader: "Payback is not computable for this window — no partner has both payout and revenue. Pick a window/network where a partner both received payout and drove revenue, or supply the pairing manually." Do not emit an all-negative table as if it were a finding.

===========================
STEP 4 — Emit the digest
===========================
Output a Markdown table sorted by Break-Even (payback_days) ascending, fastest-paying-back first:

| Rank | Partner | Conversions | Revenue | Payout | Margin % | Terms (net days) | Break-Even (days) | 30d Profitable? | Action |

Formatting: money with currency symbol + thousands separators; Margin as the percent from the report; Terms shows the number and "(ASSUMED)" when you defaulted it; Break-Even = payback_days rounded (or "n/a" per guardrail); 30d Profitable = YES / NO / n/a. Action column, pick one:
  - payback_days ≤ terms_days  → "Fast payback — safe to keep or shorten terms / grow spend."
  - terms_days < payback_days ≤ 30 → "Payback lands after your terms window — monitor; hold terms."
  - payback_days > 30 or profit ≤ 0 → "Slow / negative — extend terms (net-60+), renegotiate payout, or pause."
  - n/a → "Can't assess — revenue and payout don't co-occur for this partner."

Then a short summary section:
  - Network totals for the window (sum payout, sum revenue, sum profit) from Step 1's full set.
  - Fastest and slowest payback partner.
  - One line flagging every partner whose Terms are ASSUMED (so the reader knows to supply real terms for a firm call).
  - The explicit caveat: "Break-Even here is a steady-revenue proxy from 90-day aggregates, not a cash-timing model — Everflow's MCP exposes no payout-settlement dates, and net payment terms are user-supplied, not read from the platform."

Run it now.