get_account_info
Returns information about the current network account and the authenticated user. Call this first in any session to confirm the default currency and timezone before running reports. Parameters: None. Response fields: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 — the full catalog is also documented in Supported entity types below. Parameters:get_entity
Retrieves a single entity by its primary ID. Parameters:
Most types return the entity’s own fields. The
click, conversion, and transaction response shapes are documented on Events & Attribution.
Passing an unrecognized
type returns INVALID_ARGUMENT: Unknown entity type '…'. Call get_entity_schema with no arguments to see every supported type.list_entities
Lists entities of a given type with filters and pagination. Parameters:The
filters parameter here is a JSON object — this differs from run_performance_report, which uses comma-separated type:value strings.count_entities
Returns only the match count for a type + filter set — no records, no pagination. Use it for “how many” questions instead of paging throughlist_offers / list_affiliates / list_entities and tallying.
For a breakdown like “how many offers per category”, first fetch the group values (e.g. list_entities with type=category), then call count_entities once per value: count_entities(type="offer", filters={"category":"Finance"}), then {"category":"Insurance"}, and so on. This avoids paging entirely — counting by walking pages is wasteful and fails if a cursor is reused across a changed filter set.
“Pending partner applications” vs “pending offer applications” — different counts. A partner application is a new partner (affiliate) whose account is awaiting network approval:
count_entities(type="affiliate", filters={"status":"pending"}). An offer application is a partner requesting to run a specific offer: count_entities(type="application", filters={"status":"pending"}). Pick the type that matches the question.Status values must be exact and lowercase (e.g.
affiliate → active, inactive, pending, suspended). An unrecognized status is rejected with a suggested value — it does not silently return 0. Call get_entity_schema for a type’s valid status values.Date filters
created_after / created_before (YYYY-MM-DD, network-timezone day boundaries) are both inclusive of the named day. So “created before Jul 10” (strictly before) is created_before=Jul 09, not Jul 10. For an open-ended “since / after DATE” window, also pass created_before=today so a future-dated record can’t fall outside the window you report. Because both bounds are inclusive, a record created on the boundary day matches both created_after=DAY and created_before=DAY; when splitting a range into adjacent periods, offset the shared boundary by one day to avoid double-counting it.
Response fields:
Supported entity types
The generic tools cover 31 entity types. Three have richer documentation elsewhere:offer and affiliate have dedicated tools with more parameters — prefer those — and the event types are detailed on Events & Attribution.
Core entities
Events & attribution
People & access
Offer structure
Classification & tagging
Infrastructure & reporting
Code
0 (“no error” / accepted) has no lookup row — get_entity(type="click_error_code", id=0) returns INVALID_ARGUMENT: No click error code found for code 0. Only non-zero error codes are defined in these tables; a 0 returned on a click/conversion record simply means “accepted, no error”.Geo reference (meta)
Two entity types have non-obvious identifiers:
campaign is the API name for Smart Links (not campaigns in the general sense); and label uses the label’s text value as its id — not a numeric ID. For example: get_entity(type="label", id="top_affiliate").search_documentation
Searches Everflow’s help center and API documentation. Use this to look up feature details, setup instructions, or API endpoint specifics. Parameters:
Response: Returns an array of matching documentation entries, each with the document title, a relevant excerpt, and a link to the full source. Use
source=help_center for operational how-to content and source=api_docs for endpoint and parameter references.