New Source: Peec AI (GEO / AI search visibility)

Connector Name

Source Peec AI

Connector Description

Peec AI tracks how brands appear in answers from AI assistants — ChatGPT, Google AI Overview, Perplexity and others. This is the area usually called GEO (Generative Engine Optimisation) or AI search visibility: which brands get mentioned in generated answers, and which domains and URLs those answers cite as sources.

There is no connector for this category in the registry today, and the questions it answers ("how visible is our brand in AI answers, and which of our pages are being cited as sources") are becoming a standard part of marketing reporting.

API documentation: https://docs.peec.ai/api/introduction

Proposed streams

Stream	Grain	Sync mode
brands	one row per tracked brand	full refresh
model_channels	one row per model/channel	full refresh
brands_report	brand × model channel × month	incremental (month cursor)
domains_report	domain × model channel × month	incremental (month cursor)
urls_report	url × model channel × month	incremental (month cursor)

The two metrics most people want:

• Visibility score — visibility_count / visibility_total in brands_report. The API returns numerator and denominator separately rather than a ratio, which keeps the percentage aggregatable across periods and channels.
• Source retrievals — retrievals / retrieval_count in domains_report and urls_report.

Auth

API key, created at https://app.peec.ai/api-keys, sent as an x-api-key header.

Worth flagging because it shapes the implementation: Peec issues both project-scoped keys (prefix skp-, the common case) and company-scoped keys. A project-scoped key resolves its own project and answers 403 Not a Company API Key on GET /projects, so the connector must not depend on that endpoint — check runs against brands instead. A company-scoped key has no implicit project and needs an explicit project_id.

Implementation notes

Manifest-only (low-code). A few behaviours of this API that are worth knowing up front, all verified against live data rather than assumed:

• The report endpoints restate recent months. Peec keeps revising a month while chats are still landing in it, so the connector re-reads the previous month on every sync (lookback_window: P1M). The same month arrives more than once by design.
• urls_report has no unique key. Peec can return two rows sharing (month, url, model_channel_id) that differ only in their metrics — measured at 4 pairs in 37,844 rows. No subset of the returned fields separates them, so the stream declares no primary key and consumers must sum rather than deduplicate.
• Offset paging has no total order. limit caps at 10000 and a month can exceed that. Two walks at the same page size return the same rows in a different sequence, and order_by accepts only metric columns. Walking a month at page sizes 10000 / 7000 / 5000 returns an identical multiset every time — nothing lost or repeated — so paging is safe in practice, but the implementation ships a script that pins that invariant rather than trusting it.

Are you willing to submit a PR?

Yes — PR to follow, implementation is written and running in production.