Developer overview - StickyPrompts Docs

Use the StickyPrompts REST API and MCP server to automate work, build internal tools and bring your workspace into Claude, Cursor and other MCP clients. One API key works for both.

Everything your team builds in StickyPrompts - prompts, agents, knowledge bases, workflows, connected CRMs and databases - is also available to your own code. Call it over a plain JSON REST API, or connect an MCP client and let an AI assistant use it as a set of tools. Both run on the same engine as the web app, so the same models, guardrails and access rules apply.

One key, two doors. Everything behind them is what your workspace already has.

What you can build

Automations

Run a saved prompt on every new support ticket, process a spreadsheet row by row, or start a workflow from your own scheduler.

Internal tools

Put the models and agents your workspace already allows behind a form, a chat bot or an admin panel.

StickyPrompts in your AI client

Connect Claude Code, Cursor or VS Code over MCP and ask for “the Northwind refund policy” or “draft a follow-up to this deal”.

REST or MCP?

	REST API	MCP server
Base URL	`https://api.stickyprompts.com/api/v1`	`https://api.stickyprompts.com/mcp/` (keep the trailing slash)
Best for	Your own code: backends, scripts, scheduled jobs	AI clients that speak the Model Context Protocol
Shape	Resource endpoints (`GET /conversation`, `POST /run`, …)	Tools (`send_message`, `search_knowledge_base`, `send_email`, …)
Coverage	The widest: create and manage prompts, agents, workflows, files, projects, teams and media	A focused set of tools for reading, running and acting
Auth	`Authorization: Bearer STICKY-API-...`	The same header and the same key

Pick REST when your code decides what happens. Pick MCP when you want a model to decide which tool to call. Many teams use both with one key: MCP in the editor, REST in production jobs.

A few things exist on one side only. Semantic search inside a knowledge base is an MCP tool (search_knowledge_base) with no REST equivalent. Uploading files is REST only: the MCP server can bring files in from Google Drive with import_storage_files, but it has no upload tool.

One key for both

You create API keys yourself in Settings > API keys. Each key has a name and a set of permissions, and the full key is shown only once. The same key authenticates REST calls and MCP sessions:

Authorization: Bearer STICKY-API-<64 characters>

See API keys and authentication for the details.

A key acts as you, narrowed by its permissions

A key is not a separate service account. It acts as the user who created it: it sees your workspace, your projects and whatever has been shared with you - nothing more. Its permissions then narrow that further. A key with only knowledge_bases_get can read the knowledge bases you can read, and cannot touch your conversations.

There is no per-workspace or per-project key. You scope a key by choosing its permissions.
Workspace rules still apply to every call: model access, data residency and guardrails behave exactly as they do in the app.
Over MCP, a tool your key has no permission for does not appear in the tool list at all.

The full list is in the permissions reference.

Usage counts like app usage

API and MCP calls run through the same execution, quota and billing path as the web app. Usage is attributed to the key’s owner and their workspace like any other usage and draws on the same credits. There is no separate API price list. When the workspace is out of quota, REST calls that start paid work return 429 Quota exceeded - see Errors, pagination and quotas.

No webhooks: poll for results

The API does not send webhooks. Most calls are synchronous and return the finished result. For long-running work - video, speech, music and transcription over REST, spreadsheet processing, workflow runs - you start the job and then poll its status. A conversation started with the stream endpoint can be followed live over its WebSocket, where each frame carries the full message so far.