Fillout vs Paperform

Fillout

Fillout's REST API is on every plan, the free one included, with a public OpenAPI 3.0.1 spec, llms.txt and submission filters by date, status and text. It has eight operations and none creates or edits a form. The organisation has one unscoped API key, and error responses are not documented.

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.

Fillout

1. Build the form in the Fillout editor first. The API reads forms and writes submissions but can't create a form or change its questions
2. Read the base URL from the Developer settings page. EU-hosted accounts use https://eu-api.fillout.com/v1/api
3. Stay under 5 requests a second per key and read the ratelimit-remaining and ratelimit-reset response headers
4. Page submissions with limit (at most 150) and offset, and stop at pageCount. status=in_progress returns unfinished ones
5. Send at most 10 submissions per create call and don't retry blindly, because the call has no idempotency key

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