Airtable API 5 requests per second per base: writing back Sume results

Airtable's Web API is limited to 5 requests per second per base, and after a 429 you must wait 30 seconds before requests succeed again (Airtable rate limits, read 2026-10-02). If many Sume jobs finish together and each webhook handler writes one record, you can hit that ceiling, so queue the write-backs instead of writing from every handler.

What Airtable states

The page gives two ceilings, and a penalty that is longer than most retry loops.

Why Sume jobs make it worse

A Sume job webhook is sent once the job reaches a terminal state, so jobs submitted together tend to land together. Each delivery has a 10-second timeout per attempt, and a non-2xx response is retried (up to 10 attempts, 30 seconds apart by default, per the webhook docs).

If your handler writes to Airtable inline and gets a 429, the 30-second Airtable penalty outlasts the 10-second Sume timeout. Sume then retries, adding more traffic to a base that is already throttled.

A pattern that stays under 5 per second

• Acknowledge the Sume delivery with a 2xx as soon as you have stored the event. Use job_id as the key so a retry does not create a second row.
• Put the write-back on your own queue and drain it at a rate safely below 5 requests per second for that base.
• On an Airtable 429, pause that base's queue for 30 seconds. Do not resubmit the Sume job; the job already finished and the result is readable at its result_url.
• Keep polling status_url as a backup for deliveries that never arrive, as the Sume docs recommend.

What Sume does not do

Sume does not write to Airtable for you. It delivers the signed event, and the throttling of the Airtable side is yours to control. Batch size on the Sume side is separate: a bulk run queues up to 100 Format runs with a concurrency window, which spaces out when jobs finish, but each item still carries its own webhook.

Check before you ship

Count how many Sume jobs can finish in the same second for one base. If that number can exceed a few, add the queue. If it cannot, a direct write is fine, as long as the job_id check makes retries harmless.