Research

Find saved research by name, question, subject, or scope. Returns brief identities, states, row versions, cadence, and next-run times. The body contains items and pagination with total, limit, offset, and hasMore. No model or source-provider calls occur. A failed read is an error, not an empty library.

Requirements

Request

Responses

Read the editable plan, run progress, dated history, a section’s answer and cited web findings, or original directly read reviews. Use saved run and section IDs for comparisons over time. Compare the original questions, scope, and recorded date windows from view=run rather than the current edited plan. Reads do not start research. brief returns {brief}; progress returns {run}, null when no run exists; run requires runId and returns {run, definition, fromDateTime, toDateTime, reviewThemes, scores} from that saved execution, with null dates if not recorded yet; reviewThemes counts what each app’s new reviews raise, and scores gives each confirmed app’s published store rating with, when measurable, how many ratings arrived since the previous run of the same plan and their mean; runs returns a keyset page with items, hasMore, and nextCursor; findings returns answer, items, savedEvidence source snapshots, and pagination; each answered question’s comparison.status (changed, consistent, or insufficient) states what changed since answer.previousRunId, which is null on a first run; records returns items and pagination. Findings keep their source URL, observations, dates, relevance, and provenance. Unknown dates remain unknown. Records are the directly read source items; web sources are in findings. Run receipts omit full snapshots and answers. Back off polling when progress is unchanged.

Requirements

Request

Responses

Choose one action in command.action. prepare drafts a plan from question (8–3,000 characters); review it before start. If apps are ambiguous, continue prepare with preparedPlan from the response and selection [{ connector: "app_store", externalId, label }] from its choices, at most four. start requires requestId (UUID), name (1–120 characters), and definition; editing also requires briefId and expectedRowVersion. Reuse requestId for HTTP retries of the same start request; use a new UUID for an intentional fresh run. start returns briefId and run. add requires briefId, runId, and productId and queues the exact saved sources without a new search. The destination cannot change after addition. retry, retry_addition, and stop require briefId and runId. Retry retains original dates and reusable completed work; stop preserves sealed preview results. Preparation, search, and evidence processing use AI credits; no per-run estimate is available. A run receipt confirms queued or completed work; poll progress and read the saved findings before reporting success or adding evidence. The API key’s creator must still be an active member with edit access. Keys with no creator can read but cannot run research. comparison_plan takes productId, 1–4 remembered competitorIds, optional lenses (live, selling, buyers, customers, enterprise, momentum; the first four by default), an optional own question (8–500 characters) and acquisition (web by default, or saved_only). Each lens is one question; more than five questions is rejected. It returns the competitive landscape plan the app uses, without model or provider calls, and landscape { briefId, expectedRowVersion } for the product’s existing landscape, or null. Review the plan, then start it with those values so each answer compares with the previous run; answer.previousRunId names that run, so check its dates before calling a change weekly.

Requirements

Request

Responses

save_context takes productId and the complete context { version, website, baselineSignalIds, competitors }. website is your product’s public site: with it, a landscape reads your public pages as it reads competitors’; without it, your column answers from product context and baseline Signals only. Each competitor has a stable UUID id, name, optional website, aliases (up to five), notes (up to 1,000 characters), and signalIds (up to five). Keep at most 30 competitors per product. Read the context first. Give a new competitor a new UUID; an entry left out is removed. A stale version returns 409; reload and reconcile before retrying. Editors can save this memory. Other actions require briefId and owner or admin access. keep also requires the runId returned by a successful add and an explicit runPolicy (on_demand, daily, or weekly); it activates only the current reviewed plan after adding its findings. schedule changes an active brief using runPolicy and optional timezone. keep also accepts timezone. pause stops future automatic runs; resume restores the saved cadence; archive requires a paused brief and preserves history and Signals. Daily and weekly research consume credits when runs execute and add new sources to Discovery. Nothing notifies users of changes; read findings to report them. Schedules managed by Zentrik and workspace plan limits remain enforced. These settings are separate from Brief emails. The API key’s creator must still be an active workspace owner or admin; a run scope alone cannot manage schedules.

Requirements

Request

Responses

Read a product’s shared competitor memory, internal baseline context and linked Signal identities with view=context (default). view=sources returns paginated workspace Signals, independent of ingestion channel, with extracted research subjects when available. Use q to search names and source metadata. The context view also returns the landscape lenses and suggestions: alternatives that saved research reports evaluated and the product does not remember yet. No model or provider calls occur. A report subject or suggestion is a candidate identity, not proof of a competitive relationship. Saving a context or creating a comparison requires a separate command.

Requirements

Request

Responses