API
A defined way for one program to ask another for data or to make it do something.
The numbers and behaviors that decide whether an automation holds up, collected from each platform’s published documentation. Kept current as platforms change.
Platforms change limits and plans. These figures reflect each platform’s documentation as we read them. Check the platform’s own documentation before you design around a specific value.
Three platforms that most automations touch, with the limits that matter and what each means for your design.
| Topic | What to know |
|---|---|
| Request rate | About 100 requests per second in live mode and 25 per second in sandboxes, for most endpoints. |
| Webhook delivery | Failed deliveries are retried for up to three days in live mode. Events can arrive more than once and out of order. |
| Event history | The events list covers the last 30 days. Anything older has to be stored by you. |
| Idempotency keys | Up to 255 characters, and Stripe may remove saved keys after at least 24 hours. |
Design implication: treat every webhook as possibly duplicated or late, check the object’s current state, and use idempotency keys for writes. Read more in Stripe webhooks: retries, duplicates and order.
| Topic | What to know |
|---|---|
| Request rate | An average of about three requests per second per connection, with bursts allowed. Exceeding it returns a rate-limited response. |
| Text size | A single rich-text object holds up to 2,000 characters. |
| Array size | Arrays in a request are limited to 100 elements. |
| Request size | At most 1,000 blocks and about 500 KB per request. |
| Webhooks | Signed with a header you must verify, and retried on failure. |
Design implication: chunk long text, paginate big lists, queue requests and verify webhook signatures. See Notion API limits that break automations.
| Topic | What to know |
|---|---|
| Sheets API quota | About 300 read and 300 write requests per minute per project, and 60 per minute per user. |
| Apps Script runtime | Six minutes per run; custom functions stop at 30 seconds. |
| Daily trigger runtime | About 90 minutes on consumer accounts and 6 hours on Workspace accounts. |
| Email and fetch | Roughly 100 emails a day on consumer accounts versus 1,500 on Workspace, and 20,000 versus 100,000 URL fetches. |
Design implication: batch writes, avoid per-row calls and design triggers around quotas. See Google Sheets automation limits.
A number on its own is not useful. These five questions turn it into a design decision.
Per second, minute or day? Per user, project or connection? The unit changes everything.
UnitRejected, delayed, queued or silently dropped? Each needs a different design.
BehaviorHigher plans often raise limits. Confirm yours.
PlanSome platforms raise limits on request. Ask before redesigning.
OptionLimits bite on your busiest day, not your average one.
Peak20 words you will meet in quotes, handover documents and platform docs, each with a one-line definition and an example from a real automation. Search, or filter by topic.
A defined way for one program to ask another for data or to make it do something.
Waiting progressively longer between retries so a struggling system has time to recover.
Your private area on BoldBellows where you send logins and API keys, share files, message the team and follow milestones.
A web address that accepts requests. A webhook is delivered to an endpoint, and an API is called at one.
The agreed table that says which field in one system corresponds to which field in another.
The written record you receive at delivery: what was built, every connection and key used, and how to revoke each.
Designing an action so that doing it twice has the same result as doing it once. It prevents duplicates when events are retried.
Giving an account only the permissions it needs to do its job, and nothing more.
A defined stage of your project with its own due time. Each one has a countdown timer in your dashboard.
A standard way to let an app access your account with limited permissions and no password changing hands.
Reading a long list one page at a time, following a cursor until there are no more pages.
The data carried inside a message, such as the body of a webhook, a request or a response.
Checking a system on a schedule to see whether anything changed, instead of waiting to be told by a webhook.
A waiting line for jobs, so bursts are processed at a safe pace instead of all at once.
The maximum number of requests a platform lets you make in a period. Go over it and requests are rejected or delayed.
Comparing two systems to confirm they agree, then finding and fixing any difference.
An API key limited to specific permissions, so that a leak cannot do everything.
One batch of changes to something we built, sent together and applied together. Two rounds are included.
A safe copy of a platform for testing, where mistakes cost nothing and touch no real customers.
A message a platform sends to a web address of yours the moment something happens, such as a payment succeeding.
No term matches. Try a shorter word, or ask us on the contact form.
Five long-form articles, each built around a problem we see in real automations.
Free, in-browser, no sign-up. Open any of them from here.
How we gather, date and update the facts on this page.
From each platform’s published documentation, read and checked by the team, with the source named so you can verify it. We do not rely on forum posts or memory for figures. Where documentation is unclear, we say so instead of guessing.
When a platform changes something we have documented, and on a regular review of every figure against the official source. If you notice something that looks out of date, tell us through the contact form and we will check it.
Use them as a guide, then confirm in the platform’s documentation for your plan. Limits depend on plan, region and date, and platforms change them. The only binding figures are those in your accepted quote or order.
We start with the ones most automations touch: payments, databases and spreadsheets. Every service page lists the limits that apply to its platform pair, and we add more platform guides over time. Tell us which you would like next.
Ask through the contact form with the platform name and the limits that matter to you. If many people ask for the same one, it moves up our list, and we can often answer a specific question directly in the meantime.
Yes, with a link back. Short extracts with a clear credit are welcome, and the copyright policy explains what to ask first, such as republishing a whole guide or translating it.
Some do. Check the platform’s documentation for your account’s region and plan. Data residency, payment methods and feature availability can differ by region, and we flag the ones that matter to your project in the quote.
A rate limit caps speed, for example requests per second. A quota caps volume, for example requests per day. You can stay under a rate limit and still exhaust a quota, or the reverse, so automations are designed with both in mind.
Browse fixed-price services across 128 platforms, or request a custom quote.