Fillout vs Google Forms API

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.

Google Forms API

Six OAuth scopes separate form structure from responses, and batchUpdate applies a batch atomically with a revision check. Notifications go only to a Cloud Pub/Sub topic and carry no response data, the API can't list forms or create file upload questions, and the release notes were last updated on 8 April 2025.

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

Google Forms API

1. Call forms.create with a title only, then add items with forms.batchUpdate. Any other field in the create body is disallowed
2. Publish with forms.setPublishSettings before sharing. Google's notice says forms created through the API after 30 June 2026 start unpublished
3. Pass pageSize on forms.responses.list. With none set a page can hold up to 5,000 responses. Use filter=timestamp > N to fetch only new ones
4. After a Pub/Sub notification, call forms.responses.list yourself. The message holds only formId, watchId and eventType. Renew each watch within seven days
5. Send writeControl.requiredRevisionId on forms.batchUpdate, and read the form before retrying a timed-out forms.create, which has no idempotency key