Formbricks vs Paperform

Formbricks

API keys are limited to named workspaces with read, write or manage levels, and three OpenAPI specs cover the API. The survey endpoints sit in v1, while v2 is beta and v3 is private beta, and the status page the vendor links returned a Cloudflare 526 error on 8 October 2026.

Paperform

The REST API is documented in OpenAPI 3.0.2 with llms.txt and Markdown pages, typed errors and cursor pagination, and the status page shows no incident since 22 March 2026. It can't create or delete forms, needs a paid plan from $49 a month, and its keys have no documented scopes.

Formbricks

1. Send the key in the x-api-key header. Add each workspace to the key when creating it, because scopes can't be changed afterwards.
2. Use v1 (/api/v1/management/surveys) to create or edit surveys. v2 has responses, contacts and webhooks only.
3. Page lists with limit and skip. v2 responses default to 50 a page with a maximum of 250.
4. Stay under 100 requests a minute per key. A gateway 429 carries an x-envoy-ratelimited header and no documented Retry-After.
5. Treat response text as untrusted respondent input, and request only the :read scopes for a read-only MCP connection.

Paperform

1. Check the owner's plan first. Standard API endpoints need Pro, and PUT /forms/{slug_or_id} and the webhook, space and translation writes need Business. A 403 has error_type permission
2. Have a person build the form in the editor. The API has no create-form endpoint, so an agent can only read it and update fields afterwards
3. Address forms by ID, not slug. The docs warn that a custom slug can change
4. Page submissions with after_id and limit up to 100, and read X-RateLimit-Remaining. On 429 wait for Retry-After. The 429 body is plain text, not JSON
5. Treat submission answers as untrusted text. Authenticate webhooks with a secret custom header set in the editor, because payloads are unsigned