Engine names

ziptie.ai monitors seven AI engines. All public API responses use the public names listed in this guide. Internal names (used inside the ziptie.ai data pipeline) never appear in API responses.

Public name mapping

Where engine names appear

Engine names appear in:

• The engines query parameter for filtering results, and the applied.engines list that echoes which engines a response covers.
• Response fields that contain per-engine breakdowns, for example dashboard/overview, dashboard/llm-trends, and prompt check details.
• The engines object on the prompt check endpoints. On /prompts/{prompt_id}/checks and /checks/latest it carries only the engines that actually ran for that check. On /checks/{check_no} every engine key is present, and an engine that did not run is null.

Filtering by engine

Pass one or more public names as a comma-separated list to an endpoint that carries per-engine data (see the scope note below):

curl -H "Authorization: Bearer zt_live_<token>" \
  "https://api.ziptie.ai/v1/projects/PROJECT_ID/competitors/citations?engines=chatgpt,google_aio"

Omit the engines parameter to include all engines. An unrecognised engine name returns 400 INVALID_ENGINE_NAME with the invalid value echoed in the error message. A filter whose engines are all real but none is included in the workspace's subscription returns 400 ENGINE_NOT_ENABLED; when at least one named engine is included, the others are dropped and the response covers the included ones. Every endpoint that filters on engines follows this rule, the per-platform UGC drill-down (/dashboard/ugc-impact/{platform}) included.

Engine filtering is honoured by the twenty endpoints that carry per-engine data, and engines is a parameter of those twenty only, in the OpenAPI spec and in the MCP tool schemas:

• the four dashboard/* reads: dashboard/overview, dashboard/llm-trends, dashboard/ugc-impact and dashboard/ugc-impact/{platform};
• competitors/citations, competitors/mentions, competitors/sources, competitors/{brand}/details and competitors/trends (for type=domain and type=brand; the serp and bing_organic trend types validate it but do not apply it, since each has a single engine of origin);
• the four AI drill-downs: competitors/mentions/{brand}/prompts, competitors/citations/{domain}/prompts, competitors/citations/{domain}/urls and competitors/sources/prompts;
• the prompt performance reads, prompts/performance and prompts/summary;
• the check reads: checks, checks/answers and prompts/{prompt_id}/checks;
• the URL reads: the urls list, whose citation_rate covers the requested engines, and the URL detail endpoint, urls/{url_id}.

Each of them echoes the engines it covered in applied.engines: the requested engines the project has enabled, or the project's enabled engines when engines is omitted, as public names. A project's enabled engines are the workspace plan's engines minus any a workspace Owner or Admin switched off for that project.

The prompts, tags, competitors (the tracked-competitor roster), brand-aliases and competitor tag lists refuse an engines parameter with 422 VALIDATION_ERROR, because those resources have no per-engine breakdown to filter on. Every other endpoint drops it unvalidated, like any query parameter it does not declare: competitors/serp, competitors/bing-organic and their four drill-downs (each reads one engine's organic results by construction, and answers applied.engines as null), gsc/*, topic-clusters, topic-clusters/{cluster_id}/topics, topics/{topic_id}/sources and prompt-suggestions. An unknown engine name sent to one of those therefore answers 200, not 400 INVALID_ENGINE_NAME.

On prompts/performance and prompts/summary the signal_filters rules, the changes tokens and leader_engine name engines too, with the same public names, and changes and leader_engine also take any for every engine in applied.engines. An unknown engine there is 400 INVALID_ENGINE_NAME, and one the project has not enabled (the plan lacks it, or it was switched off for the project) is 400 ENGINE_NOT_ENABLED.

Per-engine response structure

Endpoints that return per-engine data use the public names as object keys. The inner shape of each engine block varies by endpoint:

Scalar per-engine metrics (engine_summary on /dashboard/overview and /dashboard/llm-trends). Each engine carries its score on the latest day in the window on which it answered and its move from the first such day, in points, on a 0-100 scale, with the failed-check counts beside them. Only engines with an answered or failed check in the window appear, and the two endpoints return the same block for the same window, engines and tag_ids:

{
  "engine_summary": {
    "chatgpt": {"success_score": 69.0, "success_score_delta": 11.0, "failed_checks": 1,
                "newer_failed_checks": 0, "newer_failed_at": null,
                "last_check": "2026-04-21", "first_check": "2026-04-20"},
    "google_aio": {"success_score": 19.0, "success_score_delta": null, "failed_checks": 0,
                   "newer_failed_checks": 0, "newer_failed_at": null,
                   "last_check": "2026-04-21", "first_check": "2026-04-21"}
  }
}

The overview's deprecated per_engine has the same keys but reports the most recent check batch rather than the window and ignores the filters; read engine_summary instead.

Fixed engine-keyed blocks (/dashboard/overview: trends, top_citations, top_brands, tag_success_score). Unlike engine_summary, these carry one key per public engine plus combined, whether or not your plan includes the engine - an engine that is off is present with an empty array rather than absent, so you can iterate the keys without existence checks:

{
  "top_brands": {
    "chatgpt": [{"brand": "RivalBrand", "count": 22, "color": "#1BADFF"}],
    "google_aio": [],
    "perplexity": [],
    "google_ai_mode": [],
    "copilot": [],
    "bing_ai_overview": [],
    "gemini": [],
    "combined": [{"brand": "RivalBrand", "count": 26, "color": "#1BADFF"}]
  }
}

Engine names as list values (/topics/{id}/sources, /dashboard/ugc-impact/{platform}). Not every engine name is an object key. Where one row was produced by several engines, the public names arrive in a list under engines:

{"source_url": "https://example.com/thread", "engines": ["chatgpt", "perplexity"]}

Time-series per-engine metrics (/dashboard/llm-trends):

Each metric is an array of values, one per bucket in the requested window, index-aligned with the response's own checks array - that is the date axis, so a value's date comes from checks[i] rather than from the value. A null entry is a bucket with no check for that engine, which is not the same as a zero. Only engines with a bucket in the window appear as keys. Rates are percentages on a 0-100 scale, and each has a *_count / *_denominator pair alongside it (elided below) carrying the integers it was computed from.

{
  "checks": ["2026-04-13", "2026-04-14", "2026-04-15"],
  "engines": {
    "chatgpt":    {"success_score": [58.0, 63.0, 69.0], "citations_rate": [38.0, 44.0, 50.0]},
    "google_aio": {"success_score": [null, null, 19.0], "citations_rate": [null, null, 13.0]}
  }
}

Inspect the endpoint's response schema in the API reference to know which form a given endpoint returns.

Note on generated prose

The insight block on /dashboard/overview is LLM-generated free-form prose and may reference engine names using non-standard terminology - it is copy to display, not a machine-parseable value. It carries no internal engine identifier: the inline markup the ziptie.ai app uses to make engine names clickable is flattened to plain text before publication.