Skip to main content
Peeve is an in-product agent. It lives inside your web app, and when a user asks for something it moves a real cursor to show them — navigating, filling, and stopping at the point of any write so the person takes the committing action themselves. This documentation covers what Peeve exposes to you as a developer. There are four surfaces, and they solve different problems.

The widget

A script tag on your pages. Runs the agent, handles escalation to a human, surveys, and lead capture. Authenticated with a publishable key.

The server API

Push your users to Peeve, and control the kill switch. Backend only, authenticated with a secret key.

The MCP server

A live Model Context Protocol endpoint that external assistants connect to in order to discover what your product can do.

Agent artifacts

Static files — llms.txt, AGENTS.md, server-card.json, mcp.json — that let an agent discover your product without connecting to anything.

​
Two kinds of key, and the difference matters

Everything here depends on getting this right. A publishable key is public by construction — it ships in your page and anyone can read it. That is fine, and expected. What stops it being abused is the origin check plus per-plan rate limits. A secret key is a bearer credential with full workspace authority. It never belongs in a browser, in client-side code, or in a repository.
Peeve shows every key exactly once, at creation. Secret keys are stored hashed and cannot be recovered — rotate instead. Publishable keys are stored in the clear, because they are public by design.
Read Authentication before you write any integration code.

​
Base URL

The widget script is served from https://cdn.peeve.ai/widget.js.

​
What Peeve will not do

Being clear about the limits up front saves you from designing around capabilities that do not exist.
tools/call returns a grounded guide — where a capability lives and how to complete it. It does not perform the action. This is a deliberate security decision, not a gap. See the MCP overview.
Any click on a control your page marks as committing is rewritten server-side into a confirmation step. Each write needs its own approval; an earlier confirmation never covers a later one. No instruction in page text or a tool result can waive this.
The telemetry, signal, survey and thread endpoints answer with a harmless success rather than a 4xx when a key is unknown or a limit is hit — a tracking beacon must never put a console error inside your app. Check the response body, not the status code. See Errors.
The MCP server, agent artifacts, lead capture and meeting booking all require Growth or above. See Plans and gating.