Uniki User Guide

Appearance

8.1 Understanding Rate Limits ​

You've built powerful automations with triggers, dependencies, conditions, and sub-taibles. Your taibles can process hundreds or thousands of rows automatically. But there's an important constraint you need to understand: rate limits.

This section explains what rate limits are, why they matter, and how they protect your automations from failure and unexpected costs.

The Problem: Overwhelming External Services ​

Scenario: Lead Enrichment at Scale ​

Imagine you've built a lead enrichment automation:

Setup:

  • Import 10,000 leads from CSV
  • Column calls Clearbit API to enrich each lead
  • Clearbit costs $1 per enrichment

What happens when you hit "Import":

All 10,000 API calls happen within seconds (parallel processing).

Problem 1: API Provider Rejection ​

Clearbit's rate limit: 10 requests per second

Your automation: Sending 100+ requests per second

What happens:

  • Requests 1-10: Success
  • Requests 11-100: Failed (429 Too Many Requests)
  • Requests 101+: Failed (429 Too Many Requests)

Result:

  • 10 rows enriched successfully
  • 9,990 rows failed
  • 99% failure rate
  • You still pay for the 10 that succeeded

The error message: "429 Too Many Requests - Rate limit exceeded"

Problem 2: Unexpected Costs ​

Even if API accepts all requests:

Calculation:

  • 10,000 leads × $1 per enrichment = $10,000
  • Charged immediately
  • Non-refundable

If you intended to only enrich qualified leads:

  • Should have used conditions
  • Should have throttled processing
  • Should have limited to test batch first

Oops - you just spent $10,000 on unqualified leads!

Problem 3: Service Degradation ​

Scenario: Your own API

Automation: Calls your company's internal API 1,000 times in 10 seconds

What happens to your API:

  • Servers overloaded
  • Slow responses for everyone
  • May crash entirely
  • Other users affected
  • IT team gets paged

Result: Your automation takes down production!

What Are Rate Limits? ​

Simple Definition ​

Rate limit: A restriction on how many operations can happen in a given time period.

Examples:

  • "10 API calls per second"
  • "100 emails per hour"
  • "1,000 database queries per minute"
  • "50 LLM requests per minute"

Think of it like:

  • Speed limit on highway (protect everyone)
  • Water from faucet (controlled flow)
  • Queue at store (one at a time)

Two Types of Rate Limits ​

1. External Rate Limits (Provider-Imposed) ​

Who sets it: External service (API provider, SaaS platform)

Examples:

  • Clearbit: 10 requests/second (free tier)
  • OpenAI GPT-4: 10,000 tokens/minute
  • Gmail SMTP: 500 emails/day
  • Shopify API: 2 requests/second
  • Stripe: 100 requests/second

Why they exist:

  • Protect service from overload
  • Fair usage across all customers
  • Prevent abuse
  • Tier pricing (higher limits = higher cost)

What happens if exceeded:

  • Requests rejected with error
  • Usually 429 status code
  • May result in temporary ban
  • Counts toward your quota anyway

You cannot change external rate limits (they're the provider's rules)

2. Internal Rate Limits (Self-Imposed) ​

Who sets it: You (the taible owner)

Examples:

  • "Limit my enrichment to 100 rows/hour" (cost control)
  • "Only send 50 emails/hour" (avoid spam filtering)
  • "Process 10 orders/minute" (match warehouse capacity)

Why you set them:

  • Control costs (avoid runaway spending)
  • Match downstream capacity (warehouse can only pack X/hour)
  • Stay under external limits (proactive throttling)
  • Gradual rollout (test with small batch first)
  • Business logic (spread emails throughout day)

You can adjust internal limits anytime

Why Rate Limits Matter ​

Reason 1: Prevent Automation Failure ​

Without rate limits:

Launch automation
    ↓
10,000 API calls at once
    ↓
9,990 fail (rate limit exceeded)
    ↓
Automation mostly broken
    ↓
Manual cleanup required

With rate limits:

Launch automation
    ↓
Rate limiter: Process 10 per second
    ↓
10 calls → Success
Wait 1 second
10 calls → Success
Wait 1 second
... continues smoothly
    ↓
All 10,000 succeed (takes ~16 minutes)
    ↓
100% success rate

Slower, but reliable

Reason 2: Control Costs ​

Scenario: Testing new enrichment column

Without rate limit:

  • Add column to taible with 50,000 rows
  • Column runs on all rows immediately
  • 50,000 × $1 = $50,000 charged
  • You wanted to test on 10 rows first!

With rate limit:

  • Set limit: 10 requests per hour
  • Column processes 10 rows
  • Cost: $10
  • Review results
  • If good, increase limit
  • If bad, fix and restart

Rate limit = safety net for your budget

Reason 3: Respect External Services ​

Good API citizen behavior:

Without rate limiting:

  • Hammer API with thousands of requests
  • May get account suspended
  • Poor reputation
  • API provider may block your organization

With rate limiting:

  • Respectful request patterns
  • Stay within provider limits
  • Maintain good standing
  • Long-term relationship

Professional approach

Reason 4: Match Business Constraints ​

Example: Order fulfillment

Your warehouse: Can pack 20 orders per hour

Automation: Processes orders and sends to warehouse

Without rate limit:

  • 100 orders per hour sent to warehouse
  • Warehouse overwhelmed
  • Orders pile up
  • Errors increase

With rate limit:

  • Set to 20 orders per hour
  • Matches warehouse capacity
  • Smooth operation
  • Quality maintained

Match digital to physical

How Rate Limits Work ​

The Basic Mechanism ​

Rate limiter acts as a gatekeeper:

Cells Waiting to Execute:
Cell 1
Cell 2
Cell 3
Cell 4
Cell 5
...
Rate Limiter
Limit:10 per second
Current:7 processed this second
Available:3 more allowed
→ Process next 3 cells
→ Wait for next second
→ Process next 10 cells
→ ...

The Queue ​

Cells waiting go into a queue:

Rate Limited Queue (First In, First Out)
Cell 1
Processing
Cell 2
Rate Limited
Cell 3
Rate Limited
Cell 4
Rate Limited
Cell 5
Rate Limited
...
1.Rate limiter releases Cell 1
2.Cell 1 moves to Processing
3.API call happens
4.Cell 1 completes (Done)
5.Cell 2 gets the slot and starts processing

Queued state: Blue badge, waiting for slot

When slot available:

  1. Rate limiter releases cell
  2. Cell moves to Processing
  3. API call happens
  4. Cell completes (Done)
  5. Next cell gets slot

Order: First in, first out (FIFO) - unless priority override

The Window ​

Time window determines reset:

Sliding window (most common):

Limit: 10 per minute

12:00:00 - 12:00:59 → 10 requests allowed
12:00:01 - 12:01:00 → 10 requests allowed
12:00:02 - 12:01:01 → 10 requests allowed
... (window slides continuously)

Fixed window (alternative):

Limit: 10 per minute

12:00:00 - 12:00:59 → 10 requests allowed
12:01:00 - 12:01:59 → 10 requests allowed (resets at minute boundary)

Most systems use sliding window (more smooth)

Cell States with Rate Limiting ​

New state: Rate Limited

Example: Rate Limited Cell

Rate Limited
Color: Yellow/amber background (warning)
Icon: Pause icon (⏸️)
Text: "Rate Limited"
Yellow/Amber
⏸️
Pause Icon
Rate Limited
Status Text

Cell lifecycle with rate limiting:

Cell State Lifecycle with Rate Limiting

Idle
Cell hasn't started yet
↓
Queued
Waiting to run
↓
⚡ Rate Limiter Checks Availability
Is there capacity to run this cell?
✅ Capacity Available
Running Processing...
↓
Done Completed!
⚠️ Limit Reached
Rate Limited Throttled
↓
⏱️ Wait for window reset
↓
Queued Auto-retry
↓
Running
↓
Done
💡 Key Point: Rate limited cells automatically retry when the time window permits. No manual action needed!

Rate Limited means:

  • Cell is ready to run
  • Dependencies satisfied
  • Condition passed
  • Waiting for rate limit slot
  • Will auto-retry when slot available

Multiple Rate Limits ​

A single API call might face multiple limits:

Cell must pass ALL checks before executing
Check 1: Under 10,000 TPM?
Current: 8,500 tokens/min
PASS
Check 2: Under 500 RPM?
Current: 420 requests/min
PASS
Check 3: Under 200 concurrent?
Current: 200 concurrent (AT LIMIT)
FAIL
Cell State: Rate Limited
Waiting for concurrent requests to drop below 200
Most restrictive limit determines wait time

Example: OpenAI GPT-4 API

Provider limits:

  1. 10,000 tokens per minute (TPM)
  2. 500 requests per minute (RPM)
  3. 200 concurrent requests

Your limits: 4. Budget limit: $100/day 5. Business hours only: 9 AM - 5 PM

Cell must pass ALL limits before executing

Most restrictive limit determines wait time

Rate Limit Granularity ​

Column-Level Rate Limits (Most Common) ​

Applied to: Specific column

Example: Rate limit applied to one column only
Row Email Enrich (Clearbit)
⚠️ Rate limit: 10/second
Score Lead
1 user1@example.com DoneDone
2 user2@example.com DoneDone
3 user3@example.com Rate LimitedIdle
......Rate LimitedIdle
Enrich Column (Rate Limited):
Processing 10 rows per second. Remaining rows wait in "Rate Limited" state.
Score Lead Column (No Limit):
Waits for Enrich to complete, then runs normally at full speed.

What it limits: Only that column's executions

Other columns: Unaffected, run normally

Use when: Protecting specific API or operation

Row-Level Rate Limits (Rare) ​

Applied to: Entire row (all columns)

Example:

Row rate limit: 5 rows per minute

What it limits: No more than 5 rows processing simultaneously

Use when:

  • Downstream system has global limits
  • Cost control across all operations
  • Complex dependencies

Less common: Usually column-level is sufficient

Organization-Level Rate Limits (Global) ​

Applied to: Entire organization (all taibles)

Example:

Organization limit: 10,000 API calls per day (any API)

What it limits: Total API calls across all your automations

Set by: Platform (Taibles system) or subscription tier

Purpose:

  • Fair usage across all customers
  • Prevent abuse
  • Tier pricing

You see: Daily quota dashboard

Types of Rate Limit Metrics ​

Request-Based Limits ​

What's counted: Number of requests

Format: "X requests per Y time"

Examples:

  • 10 requests per second
  • 100 requests per hour
  • 1,000 requests per day

Simple and common: Most APIs use this

Token-Based Limits (AI/LLM) ​

What's counted: Tokens (word pieces) processed

Format: "X tokens per Y time"

Examples:

  • OpenAI: 10,000 tokens per minute
  • Anthropic Claude: 100,000 tokens per minute

Token calculation:

Prompt: "Classify this email" = ~4 tokens
Email content: "Hello, I need help..." = ~50 tokens
Response: "Category: Support" = ~5 tokens
Total: ~59 tokens per request

Varies by request: Longer prompts = more tokens

Rate limit depends on token count, not request count

Cost-Based Limits ​

What's counted: Dollar amount spent

Format: "Max $X per Y time"

Examples:

  • $100 per day
  • $1,000 per month

Purpose: Budget protection

Example: Budget-based rate limiting
Hourly Budget$50 / $50
Budget exhausted - resets next hour
12:00 PM
Calls 1-50: Allowed ($1 each = $50)
12:15 PM
Call 51: Rate Limited (budget exhausted)
⏱️ Waiting for next hour...
1:00 PM
Budget resets: $50 available again
1:00 PM
Call 51: Allowed (new budget)

Concurrency Limits ​

What's counted: Simultaneous operations

Format: "Max X concurrent requests"

Example: "Max 10 concurrent API calls"

Example: Maximum 10 concurrent API calls
Currently Running:10 / 10 concurrent
Cell 11 wants to run: Rate Limited (10 concurrent already running)
One API call completes (now 9 concurrent)
Cell 11: Allowed (now 10 concurrent again)
Not time-based: Depends on completion, not the clock

Not time-based: Depends on completion, not clock

Rate Limit Behavior ​

What Happens When Limit Reached ​

Sequence:

  1. Cell ready to execute

    • Dependencies: Done
    • Condition: True
    • Moves to Queued

  2. Rate limiter checks

    • Current usage: 10/10 (at limit)
    • Decision: Deny

  3. Cell state → Rate Limited

    • Yellow badge
    • Icon: Pause
    • Tooltip: "Rate limited - retrying in 45s"

  4. Auto-retry

    • System tracks when slot opens
    • Automatically retries at that time
    • No manual intervention needed

  5. Slot opens

    • Time window passed
    • OR previous request completed
    • Rate limiter releases cell

  6. Cell executes

    • State → Processing
    • API call happens
    • State → Done

Fully automatic: No action needed from you

Retry Logic ​

Built-in retry for rate-limited cells:

Intelligent scheduling (Taibles):

Rate limit: 10 per second
100 cells waiting

Schedule:
Second 1: Process cells 1-10
Second 2: Process cells 11-20
Second 3: Process cells 21-30
...
Second 10: Process cells 91-100

Optimal throughput: No wasted retries

Priority in Rate-Limited Queues ​

Not all cells are equal:

Rate Limited Queue with Priority (Limit: 10 per second)
Position 1
User-triggered cell
Priority: 1000 (Highest)
Goes First
Position 2
High-priority row
Priority: 100
Position 3
Standard row
Priority: 10
Position 4
Standard row
Priority: 10
...
Position 50
Background task
Priority: 1 (Lowest)
Goes Last
User interactions jump the queue

Priority levels:

  1. User-triggered (manual run): Highest priority
  2. High-priority rows: High
  3. Standard automation: Normal
  4. Background tasks: Low

User interactions jump the queue

Rate Limits and Dependencies ​

Downstream Impact ​

Scenario: Column B depends on Column A

Column A: Rate limited to 10 per second

Columns B and C both depend on A (independent of each other)
Column A
Rate limited: 10/sec
Column B
No rate limit
Column C
No rate limit
Row 1:
Second 1
A: Executes
Immediate
B and C: Both execute immediately (parallel)
Row 11:
Wait
A: Rate Limited (wait until second 2)
Wait
B: Idle (waiting for A)
Wait
C: Idle (waiting for A)
⏱️ 1 second passes...
Second 2
A: Executes
Immediate
B and C: Both execute immediately (parallel)
Bottleneck: Column A slows both B and C

Rate limit cascades: Slow column slows downstream

Parallel Columns ​

Scenario: Columns B and C both depend on A, but independent of each other

Row Column A
Rate: 10/sec
Column B
Depends on A
Column C
Depends on A
1DoneDoneDone
11Rate LimitedIdleIdle
Column A
Rate limited: 10/sec
Column B
No rate limit
Column C
No rate limit
Bottleneck: Column A is rate limited, so both B and C must wait
Even though B and C can run in parallel, they both need A to complete first

Bottleneck: Column A slows both B and C

Benefits of Rate Limiting ​

Benefit 1: Reliability ​

With proper rate limiting:

  • 100% success rate (all cells eventually succeed)
  • No 429 errors
  • No API bans
  • Predictable execution

Worth the wait: Slower but reliable

Benefit 2: Cost Predictability ​

Budget protection:

  • Set daily/hourly spend limit
  • Automation stops when limit reached
  • Review before increasing
  • No surprises on credit card
Example: Daily budget protection ($100 limit)
8:00 AM
Automation starts
Daily limit: $100 | Cost per call: $1
8:00-10:00 AM
Processes 100 calls
Spent: $100 of $100
10:00 AM
Hits daily limit
Stops automatically
📧 Alert sent
"Daily limit reached - review results"
10:30 AM
You review results
Decide: Keep limit or adjust
Next Day
Resumes automatically
New daily budget: $100
No surprises on credit card - budget protected!

Benefit 3: Graceful Degradation ​

When external API slows:

Without rate limiting:

  • Keep hammering slow API
  • Compound the problem
  • Eventually: complete failure

With rate limiting:

  • Detect slowness
  • Reduce request rate automatically
  • Adapt to conditions
  • Maintain partial service

Resilient system

Benefit 4: Testing Safety ​

When testing new automation:

Set conservative limit:

  • Test run: 10 rows per hour
  • If successful: Increase to 100 per hour
  • If still good: Increase to 1,000 per hour
  • Gradual rollout

Catch issues early with small batch

Prevent: $50,000 mistake from affecting 50,000 rows

Common Rate Limit Scenarios ​

Scenario 1: Free Tier API ​

Provider: Clearbit (free tier)

Limits:

  • 50 requests per month
  • 1 request per second

Your taible: 10,000 leads to enrich

Without rate limiting:

  • Try to enrich all 10,000
  • First 50 succeed
  • Remaining 9,950 fail
  • Monthly quota exhausted in 1 minute

With rate limiting:

  • Set to: 1 per second, 50 per month
  • First 50 leads enriched over 50 seconds
  • Remaining 9,950 stay Rate Limited
  • Alert: "Monthly quota reached"
  • Next month: Resumes automatically

Or: Upgrade to paid tier for higher limits

Scenario 2: Email Sending ​

Provider: Gmail SMTP

Limits:

  • 500 emails per day (free account)
  • 100 emails per hour

Your automation: Welcome email to 1,000 new users

With rate limiting:

  • Set to: 90 per hour (buffer below 100)
  • Hour 1: Send 90 emails
  • Hour 2: Send 90 emails
  • Hour 3: Send 90 emails
  • ...
  • Hour 12: All 1,000 sent

Takes 12 hours, but all delivered successfully

Alternative: Use transactional email service (SendGrid, Mailgun) with higher limits

Scenario 3: LLM Processing ​

Provider: OpenAI GPT-4

Limits:

  • 10,000 tokens per minute
  • 500 requests per minute

Your automation: Classify 1,000 support tickets

Each request:

  • Prompt: ~100 tokens
  • Response: ~50 tokens
  • Total: ~150 tokens per request

Math:

  • 10,000 tokens ÷ 150 tokens per request = ~66 requests per minute (token limit)
  • Also: 500 requests per minute (request limit)
  • Effective limit: 66 per minute (token limit is more restrictive)

With rate limiting:

  • Set to: 60 per minute (buffer)
  • 1,000 tickets ÷ 60 per minute = ~17 minutes
  • All tickets classified successfully

Scenario 4: Internal API ​

Your company API: /api/warehouse/reserve-stock

Capacity: Can handle 20 requests per second

Your automation: Reserve stock for 500 orders

With rate limiting:

  • Set to: 15 per second (buffer)
  • 500 orders ÷ 15 per second = ~33 seconds
  • API stays healthy
  • No overload

Without rate limiting:

  • 500 requests at once
  • API crashes
  • Manual intervention required
  • Orders delayed

Rate Limits in Context ​

Part of Professional Automation ​

Rate limiting is not a limitation—it's a feature:

  • Reliability: Ensure success
  • Cost control: Protect budget
  • Respect: Good API citizenship
  • Scaling: Handle growth gracefully
  • Testing: Safe experimentation

Professional automations always include rate limiting

Think of it as: Cruise control for your automation

The Trade-off ​

Speed vs. Reliability:

Without rate limiting:

  • Fast (when it works)
  • Unreliable (often fails)
  • Expensive (no control)

With rate limiting:

  • Slower (controlled pace)
  • Reliable (always succeeds)
  • Predictable (budget protected)

Choose: Slow and steady wins the race

Summary: Rate Limits Explained ​

You now understand:

What rate limits are: Restrictions on operations per time period

Two types:

  • External (provider-imposed)
  • Internal (self-imposed)

Why they matter:

  • Prevent failure
  • Control costs
  • Respect services
  • Match business constraints

How they work:

  • Queue mechanism
  • Time windows
  • Auto-retry
  • Rate Limited state

Types of metrics:

  • Request-based
  • Token-based (AI)
  • Cost-based
  • Concurrency-based

Benefits:

  • Reliability
  • Cost predictability
  • Graceful degradation
  • Testing safety

Common scenarios:

  • Free tier APIs
  • Email sending
  • LLM processing
  • Internal APIs

Next Steps ​

Now that you understand rate limits conceptually, Section 8.2 will show you:

  • How to configure rate limits in the UI
  • Where to set limits on columns
  • How to adjust limits
  • Testing rate limit configurations
  • Monitoring rate limit status

Let's configure rate limits!

Built with VitePress

Copyright © 2025 Uniki