- The project's actions, the ones Peec generated and the ones the customer wrote themselves alike: what to do, on which page or site, and how much impact it is expected to have if it is done. `created_by` says which of the two an action is, and only a customer's own can be deleted or reshaped. Filters combine with AND, except `targets`, `groups`, `archetypes` and `platforms`, which combine with OR across the four. The action detail endpoint carries a single action's steps, brief, evidence and impacted prompts.
- One action in full: what to do, the fields the customer owns on it — notes, priority, assignee, due date, tags and repeat — the steps to work through, the content brief when there is one with its sections, the competitor demand behind it, the prompts it affects and the terms competitors use on the topic. A site audit action carries no brief and no opportunity, and its description and steps are the whole fix. An id this project has no published action for is a 404, whether it belongs to another project, to an action type this API does not publish for the project, or to nothing at all. A content optimisation's article, suggestions and score are not returned here, and the Customer API publishes no endpoint that returns them.
- The third-party sites a project has actions on, as values for the action list's `platforms` filter. A platform is whichever domain AI engines cite for this brand, so the set is per project and open-ended. Own-site actions carry no platform and are absent here.
- Record work the customer decided to do themselves as actions, in the same shape as the ones Peec generates, so they sort, filter and move through the same statuses. The kind picked decides an action's type and group. The linked topic and prompts are resolved against the project, and an item naming one it does not hold lands in `rejected` on its own — the batch never fails as a whole.
- Rewrite the fields a customer owns, on actions they wrote or ones Peec generated. An edit is stored beside the generated wording rather than in it, so a regeneration cannot discard it. Only a customer's own action can change shape: the type and group of a generated one say what Peec found, and an item trying to move them lands in `rejected`. A field the item leaves out keeps what it held; `null` clears the ones that can be cleared, and an item naming no field at all is rejected rather than recorded as an edit. Ids the project publishes no action under are returned in `skipped` — the batch never fails as a whole. A content optimisation is reachable only on a project with content optimisation enabled; elsewhere its id is returned in `skipped`.
- Remove actions the customer wrote themselves. A generated action reads here exactly as a missing one does and lands in `skipped`: those are declined or dismissed through the status endpoint instead, so the list keeps a record of what Peec suggested and the customer turned down.
- Move actions to a status by id: accept, reject, complete, delete, or send one back to `PENDING`. Ids the project publishes no action under are returned in `skipped` — the batch never fails as a whole. An action that is already deleted reads as absent unless the key is a platform admin one. A content optimisation is reachable only on a project with content optimisation enabled; elsewhere its id is returned in `skipped`.
- Record which of an action's steps are done. Each entry names one action and either sets `completed` for every step it holds, or lists the steps to write; a step in turn either sets `completed` for all of its options or names them individually, each with its own value, so one call can tick some and untick others. An action is all or nothing: anything Peec cannot apply leaves every step on it untouched and comes back under `skipped` or `rejected`, so a partly-written action is never a state you have to read back. Other actions in the same call are unaffected. The action's own status is never changed by this endpoint, including when every step on it is complete. An action that is already deleted reads as absent unless the key is a platform admin one. A content optimisation is reachable only on a project with content optimisation enabled; elsewhere its id is returned in `skipped`.
- List the brands of a project
- Create a new brand within a project
- List the social channels configured for a project, optionally filtered to one brand.
- Delete a brand within a project.
- Update a brand within a project. Changes to name, regex, or aliases trigger a background recalculation of metrics. While recalculation is in progress, further updates to these fields are blocked (409 Conflict) until it completes.
- Replace the complete list of social channels configured for a brand. Pass an empty list to remove them all.
- List a project's product categories. Each row carries its full `path` and its `parent_id`, so the flat list reconstructs the category tree. Use the returned `id` as a `category_id` when creating, updating, or assigning products.
- Create product categories. Each item takes a `name` and an optional `parent_id` (omit or null for a top-level category). Items apply in order. Returns per-item results { created, rejected } — the batch never fails as a whole. Rejection reasons: parent_not_found, name_conflict (a sibling already has that name).
- Rename and/or reparent categories by id. Each item sets `name` (rename), `parent_id` (move; null = promote to top level), or both — at least one is required. A combined edit is applied move-then-rename. Returns per-item results { updated, rejected } — the batch never fails as a whole. Rejection reasons: not_found, name_conflict, invalid_move (would nest a category inside itself).
- Delete categories by id. Each one's child categories and products move up to its parent, then it is removed. Returns per-item results { deleted, rejected } — the batch never fails as a whole. Rejection reasons: not_found, name_conflict (a child moving up would clash with an existing sibling name).
- List the custom URL classifications defined for a project. These complement the built-in classifications and can be assigned to URLs.
- Search Peec's global brand catalog — the shared registry of real-world brands that products attach to via `global_brand_id`. Use it to find the `global_brand_id` for a brand when creating products. This is separate from `GET /brands`, which lists the brands a project tracks for AI-visibility reporting; the two use different ids. Primarily used with `search`. Pass `ownership` (`own`, `competitor`, or `all`) instead to list the project's shopping brands ranked by mentions, for use as shopping brand filters.
- List the model channels a project's reports can be broken down and filtered by. A model channel is a stable identifier for an AI surface — openai-0 is ChatGPT UI, perplexity-1 the Perplexity API — that stays constant as the model behind it is upgraded or replaced, so filtering by channel keeps a continuous view of a surface where filtering by model fragments it across ids. The returned ids are what every model_channel_ids filter on this connector accepts.
- List the individual AI model versions a project has answers from. Peec documents this endpoint as deprecated in favour of List Model Channels, and a channel is the better filter for anything trending over time; it remains the way to resolve the model_ids filter that Get Shopping Attributes accepts, which takes model versions rather than channels.
- List a project's products with headline metrics (mention_count, win_count, avg_position, avg_rating, visibility, share_of_voice) over the date range, filterable by category, merchant, brand, country, model channel, topic, and tag. Paginated.
- Get one product's detail over a date range: headline metrics (visibility, win_rate, avg_position, avg_rating, mention_count) plus a delta for each against the immediately preceding equal-length period, the catalog metadata (brand, description, image, source, first-seen date), the effective price range with any overrides, and the median AI-mention price. Visibility is divided by the product's relevant-prompt chats, not all shopping chats. avg_rating is the mean 0–5 star rating across the product's AI mentions (null when none carried a rating). Returns data: null when the product is not in the project.
- The LLM-extracted attribute comparison grid for a product (scope=product) or the whole catalog (scope=overview), split by tab into characteristics, facts, and dimensions. Columns are competing brands (compare_by=brand) or competing products (compare_by=product, scope=product only). Deltas are computed against an explicit comparison window (previous_start_date/previous_end_date) or the equal-length window immediately before.
- Return aggregate shopping metrics over a date range. Delta fields compare against an explicit previous window or the auto-derived previous period.
- Return a product or brand shopping time series over a date range. Requires bucket and exactly one of product_ids or brand_ids.
- List ranked product or category shopping performance over a date range.
- List top shopping queries, web-search fan-out queries, or query terms over a date range.
- List the merchants (sellers) whose product offers surfaced in AI answers, ranked over a date range: mentions, share of voice against the other merchants, buy-box win rate, average position, and average star rating, each with a delta against the previous window. Scope the population with category_ids or product_ids to get per-category or per-product seller breakdowns.
- Create products. Each item is independent: valid products are created and per-item failures are returned in `rejected`, so the batch never fails as a whole. Optional `category_ids` assigns the product to categories.
- Update products (name, description, image, price overrides, categories). Each item is independent: items with nothing to apply (not found, no changes, duplicate id) are reported in `skipped`, and unsatisfiable changes (name conflict, unknown category) in `rejected`, so the batch never fails as a whole.
- Delete products. Ids that don't exist in the project are returned in `skipped`.
- List the prompts of a project
- List the tags of a project. Tags include user-created tags and Peec-managed system tags (is_system=true). Each tag carries a `group`: for system tags this is the mutually-exclusive dimension (branding or intentType); for user tags it is the user-defined group name (or null). Pass `group` to filter to a single user-defined group. System tags cannot be edited or deleted.
- List the topics of a project
No matching actions