Fillout vs Tally

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.

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.

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

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