Paperform vs Tally

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.

Tally

The REST API is free on every plan, with a public OpenAPI 3.0 spec, llms.txt, date-based versions and typed block schemas for building forms. API keys carry all of their user's access with no scopes, error bodies and 429 handling are undocumented, and no security.txt, certification or bug bounty was found.

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

Tally

1. Send tally-version on every request. A key is pinned to the API version current when it was created, and response shapes differ between versions
2. Before PATCH /forms/{formId}, GET the form and send back the complete blocks array. Blocks left out are deleted
3. Generate a UUID for every block, and make the first block a FORM_TITLE. Its payload.title becomes the form's name
4. Stay under 100 requests a minute and use a webhook for new submissions. No Retry-After header is documented, so back off on 429 yourself
5. Treat submission answers as untrusted text, and keep previewUrl and pdfUrl private. Each is a signed link with an access token and no expiry