Skip to main content
Four generic tools cover every entity on your network that doesn’t have a dedicated tool — clicks, conversions, transactions, orders, creatives, caps, coupon codes, invoices, advertisers, and more. Two utility tools round out the set.
The three entity tools are always visible in your client’s tool list, but access is enforced per type at call time. A key without Advertiser permission gets PERMISSION_DENIED on type="advertiser" while still reading type="click". See Permissions for the module each data type needs.

​
get_entity

Retrieves a single entity by its primary ID, for any of the 34 supported types. Requires: varies by type — see Permissions Ask for it: “Pull up conversion 88213.” Parameters Example
Returns Most types return the entity’s own fields. The event types — click, conversion, transaction, order — have richer shapes, documented in Event response fields below. Gotchas
  • An unrecognized type returns INVALID_ARGUMENT: Unknown entity type '…'. Call get_entity_schema with no arguments to list every supported type.
  • Two types have non-obvious identifiers: campaign is the API name for Smart Links, and label uses the label’s text as its id — get_entity(type="label", id="top_affiliate").
  • Prefer get_offer and get_affiliate over type="offer" / type="affiliate" — the dedicated tools accept more parameters.

​
list_entities

Lists entities of a given type with filters and cursor pagination. Requires: varies by type — see Permissions Ask for it: “List the coupon codes assigned to partner 142.” Parameters Example
Returns Gotchas
  • filters here is a JSON object. run_performance_report uses comma-separated type:value strings instead. They are not interchangeable.
  • click_error_code and conversion_error_code are exceptions. These fixed reference tables are returned whole in a single response, emitting { total, <type>s } with no rows_returned, has_more, next_cursor or page_size. A supplied page_size is accepted but ignored — don’t attempt to page them.
  • Some types require a filter before they will list: offer_url needs offer_id, city needs region_id, advertiser_event needs advertiser_id or offer_id, and coupon_code needs at least one of its identifying filters.

​
count_entities

Returns only the match count for a type and filter set — no records, no pagination. Use it for “how many” questions instead of paging through a list and tallying. Requires: varies by type — see Permissions Ask for it: “How many partner applications are pending?” Parameters Example
Returns Gotchas
  • “Pending partner applications” and “pending offer applications” are different counts. A partner application is a new partner whose account awaits approval: type="affiliate", {"status":"pending"}. An offer application is a partner requesting a specific offer: type="application", {"status":"pending"}.
  • Status values must be exact and lowercase (e.g. affiliate → active, inactive, pending, suspended). An unrecognized status is rejected with a suggestion — it does not silently return 0.
  • created_after and created_before are both inclusive of the named day (YYYY-MM-DD, network-timezone boundaries). “Created before Jul 10” is created_before=2026-07-09. Because both bounds are inclusive, a record created on a shared boundary day matches both adjacent windows — offset the boundary by one day when splitting a range, or you’ll double-count it.
  • For an open-ended “since DATE” window, also pass created_before=today so a future-dated record can’t fall outside the window you report.
  • For a breakdown, fetch the group values first (e.g. list_entities(type="category")), then call count_entities once per value. That beats paging, which is wasteful and breaks if a cursor is reused across a changed filter set.

​
get_entity_schema

Returns the available filters, include options, and field descriptions for any entity type. Call it with no arguments to list every supported type. Requires: none Ask for it: “What can I filter coupon codes by?” Parameters Example
Returns The type’s filters, relationship includes, and field descriptions. With no type, the full catalog of supported types — also documented in Supported entity types.

​
get_account_info

Returns information about the current network account and the authenticated user. Requires: Control Center → Accounts (Read Only) Ask for it: “What timezone and currency does my network report in?” Parameters None. Example
Returns Gotchas
  • Call this first in any session. Reports default to the network’s timezone and currency, and knowing them up front stops numbers being misread later.
  • current_user.is_limited_affiliate_scope explains silently low counts elsewhere — a limited-scope key never sees affiliates outside its scope, in any tool.
  • Check modules before assuming a metric exists. If impressions tracking or view-through attribution is off for the network, the matching metrics come back as zero rather than as an error.

​
search_documentation

Searches Everflow’s help center and API documentation. Use it to look up feature details, setup instructions, or API endpoint specifics. Requires: none Ask for it: “How does Everflow handle view-through attribution?” Parameters Example
Returns An array of matching documentation entries, each with the document title, a relevant excerpt, and a link to the full source. Gotchas
  • Use source=help_center for operational how-to content, and source=api_docs for endpoint and parameter references.

​
Supported entity types

The generic tools cover 34 entity types. Three have richer documentation elsewhere: offer and affiliate have dedicated tools with more parameters — prefer those — and the event types have their full response shapes in Event response fields below.

​
Permission by type

get_entity, list_entities and count_entities are always visible in your tool list, but each call is authorized against the type you pass. This is the full map — a type whose module your key lacks returns PERMISSION_DENIED.

​
Core entities

​
Events & attribution

​
People & access

​
Offer structure

​
Classification & tagging

​
Infrastructure & reporting

​
Geo reference (meta)

​
Event response fields

Clicks, conversions, transactions and orders are read through get_entity and list_entities like any other type, but their response shapes are large enough to warrant their own reference. For the workflow that uses them together, see Attribution debugging.
Most empty, zero, or false fields are omitted, so any given record carries only a subset of the keys below (campaign_id, error_message, coupon_code, is_view_through and is_test_mode appear only when set). A few string fields (browser, os_version, referer, coupon_code) may instead come back as an empty string "" — treat “key absent” and “empty string” the same way.
get_entity(type="click", id="<32-char transaction ID>")Response fields: transaction_id, timestamp, offer_id, offer_name, affiliate_id, affiliate_name, advertiser_id, advertiser_name, campaign_id, error_code, error_message, is_unique, is_view_through, is_test_mode, payout, revenue, currency, country, region, city, browser, platform, device_type, os_version, user_ip, sub1–sub10, source_id, referer, coupon_code, has_conversion, previous_transaction_id.offer_name, affiliate_name, advertiser_name and has_conversion are resolved only on the single-record lookup — they need a per-record query that would be an N+1 across a 1,000-row stream, so search_activity omits them. Everything else is identical on both.Listing filters — list_entities(type="click", filters=…):
get_entity(type="conversion", id="<conversion ID>")Response fields: conversion_id, transaction_id, timestamp, click_timestamp, status, error_code, error_message, offer_id, offer_name, affiliate_id, affiliate_name, advertiser_id, advertiser_name, campaign_id, payout, revenue, sale_amount, payout_type, revenue_type, currency, event_id, event_name, order_id, coupon_code, email, notes, is_scrub, is_view_through, country, region, city, platform, device_type, browser, os_version, sub1–sub10, adv1–adv10, source_id, referer, language, brand, dma, device_model, previous_offer_id, session_user_ip, conversion_user_ip, http_user_agent, isp, carrier, app_id, idfa, google_ad_id, android_id.error_message and campaign_id are resolved only on the single-record lookup; search_activity omits them.
Identity fields carry the same masking as the REST conversion export. session_user_ip and conversion_user_ip are abbreviated for conversions from GDPR countries; idfa, google_ad_id and android_id have their trailing characters replaced; email is obfuscated — the local part masked, leaving the first character and the domain (a*******@example.com) — and returned unchanged otherwise, or omitted entirely when the conversion carries no email. http_user_agent, isp, carrier and app_id are returned as recorded. Treat all of these as personal data.
Listing filters — list_entities(type="conversion", filters=…):All conversions on one transaction: list_entities(type="conversion", filters={"transaction_id":"<32-char id>"}) is the flat alternative to get_entity(type="transaction"). It returns the same conversions, but cursor-paginated instead of capped at 10, and without the click / pixel / on-hold wrapper. Because it’s an indexed lookup, no from/to window is required.
get_entity(type="transaction", id="<32-char transaction ID>")Returns the full attribution chain in one call. Transactions are fetched by ID only; there are no listing filters.Each collection is capped at 10 items to stay within the context window. For each, the response includes <name>_total and <name>_returned; a <name>_truncated: true flag is added only when the collection exceeded the cap. Compare <name>_total with <name>_returned to detect more than what’s shown. When conversions are truncated, conversions_note gives the exact list_entities call to page through all of them.
get_entity(type="order", id="<store order id>")An e-commerce order ingested from a store integration. Use it to map a store order id back to the store it came from — for Shopify, the .myshopify.com URL — and to the transaction it generated. The id is the store’s order id (the long Shopify order id, not the 32-char transaction ID).Response fields: order_id, order_number, transaction_id, source, integration_id, shopify_store_url, offer_id, affiliate_id, customer_email, total, timestamp, items (each: product_id, sku, name, quantity, price). shopify_store_url is populated for Shopify orders only; integration_id is the store’s integration ID on the network.Listing filters — list_entities(type="order", filters=…):The by-integration listing is backed by the order line-item table, not the order store, so it returns a lighter record (no total, customer_email, offer/affiliate ids, or line items — fetch a single order by id for those) and excludes orders that have no line items. It’s scanned newest-first in bounded chunks; a has_more: true with a note means more orders match or the scan budget was reached — narrow the window to see the rest.