VerveKit is the set of tools that sit alongside the API catalog. Same account, same key, same credit balance — no separate signup, no second bill, nothing extra to authenticate against.
They exist because integrating an API is rarely just the call. You need something to build against before the endpoint is wired up, somewhere to put configuration that is not worth a service, a form on a page that must not carry your key, and increasingly a way to hand the whole catalog to an agent.
The tools
MCP server — the catalog as native tools for an AI client. Hosted, with input and output schemas, so an agent gets structured results rather than prose it has to parse. Discovery is free; a tool call costs what the endpoint costs.
JSON bins — JSON behind a key-protected URL. Feature flags, config, copy, sample data. Static everywhere, writable on Pro and above.
Mock endpoints — fake API responses at paths you define, with your status codes and headers. For building ahead of a backend and for testing the failure paths a real API will not produce on demand.
Embedded forms — a generated form for any endpoint, dropped into your page with two lines of HTML, authenticating with a form token rather than your API key.
What they have in common
One key. Everything here authenticates with the same x-api-key header as the API. There is
no second credential to manage and no separate console. See authentication.
One balance. Reads, submissions and tool calls all draw on your monthly credits at the normal rate. Nothing here is billed separately, and nothing here has its own allowance to run out of independently. See plans.
One set of limits. Rate limits, concurrency and the max response size apply exactly as they do to API calls, and the key restrictions that scope a key cover VerveKit tools too — a key issued to a client can be blocked from creating mocks while keeping the two endpoints it needs.
One usage view. Everything appears in analytics alongside your API traffic, so a form that suddenly gets popular is visible in the same place a runaway job is.
What each plan includes
| Plan | JSON bins | Mock endpoints | Embedded forms | APIs per GraphQL query |
|---|---|---|---|---|
| Free | 1 | 1 | Not included | 1 |
| Starter | 10 | 10 | Not included | 100 |
| Pro | 50 | 50 | 10 | 250 |
| Mega | 100 | 100 | 30 | No limit |
The MCP server has no separate allowance — it costs what the endpoints it calls cost.
Created here, called from anywhere
Bins, mocks and forms are created and deleted in the dashboard, never over the API. Attempting
either returns a 403 pointing you back to it.
That is a deliberate blast-radius decision rather than a missing feature: your key is on servers, in CI and possibly in a colleague's laptop, and none of those places should be able to delete the configuration your production app reads or wipe the mocks your test suite depends on. Reading and updating are open to the API, because those are the operations worth scripting and neither can destroy something that is not already there.
The MCP server is the exception, because there is nothing to create — it exposes the catalog you already have.
Where to start
If you are building a client before the API exists, start with mock endpoints.
If you need configuration you can change without a deploy, start with JSON bins.
If you want a lookup tool on a public page, start with embedded forms — and read the allowed-domains and CAPTCHA sections before you publish.
If you are wiring the catalog into an agent, start with the MCP server.
Next
GraphQL is the other platform surface — one request across several endpoints, on the same key and the same credits.