Bank Statement API Rate Optimization: Handling Peak Processing Loads Without Throttling

API rate optimization for bank statement processing requires six proactive strategies: exponential backoff with jitter, concurrency-controlled request queuing, webhook-based async processing, proactive rate limit header monitoring, off-peak batch scheduling, and request deduplication. Unlike generic REST APIs, document-upload APIs face unique throughput constraints driven by file size and multi-page PDF parsing latency.

Why Bank Statement Processing Hits Rate Limits Faster Than You Expect

Bank statement parsing isn't a lightweight REST call. Each request uploads a file via multipart/form-data, which consumes significantly more bandwidth and server-side processing time than a JSON payload. Add multi-page PDFs from hundreds of different banks, and you have unpredictable parsing latency that spikes hard under load.

The deeper problem is compounding. A single document job doesn't cost one API call — it costs many. File upload, parse trigger, and status polls can stack a single document into 5–10 requests against the same rate limit bucket. At 100 concurrent documents, that's potentially 1,000 requests before a single result arrives.

The Document-Upload API Difference

File-based APIs behave fundamentally differently from pure REST endpoints. A typical REST call carries a few kilobytes of JSON. A scanned, multi-page bank statement PDF can run to several megabytes — and that payload difference changes everything about throughput characteristics.

Token budgets deplete faster when each call carries megabytes, not kilobytes. Parsing latency also varies widely depending on document complexity. A clean digital PDF from a major bank parses quickly. A scanned, rotated, 12-page statement from a smaller regional institution takes much longer. Generic rate limit guides ignore this variance entirely.

For a closer look at what happens inside each parsing request, see our PDF to JSON parsing pipeline guide — it explains why parsing overhead scales non-linearly with document complexity.

Real-World Peak Load Scenarios

Three scenarios consistently produce rate limit collisions in production:

• MCA brokers: End-of-month underwriting surges push hundreds of applications through simultaneously. An entire pipeline submits in minutes, not hours.
• CPA firms: Tax season creates concentrated bulk processing windows across dozens of clients, all on a single API key.
• Multi-tenant platforms: A shared API key serving many clients means one high-volume client can exhaust tokens that all other clients depend on.

These aren't edge cases — they're the normal operating pattern for fintech platforms at scale. Our guide to batch processing bank statements covers how volume patterns develop over a typical underwriting month and how to plan accordingly.

Understanding API Rate Limiting: Tokens, Windows, and Throttle Responses

Rate limiting caps the number of requests allowed within a defined time window and returns an HTTP 429 error when you exceed it. Throttling is different — it slows or queues excess requests rather than rejecting them outright. The distinction matters because a throttled request still completes; a rate-limited request fails and requires a retry.

Most document parsing APIs — including ClearStaq — use the token bucket algorithm. Tokens accumulate over time up to a maximum bucket size. Each request consumes one or more tokens. Short bursts are allowed as long as the bucket has tokens. When the bucket empties, further requests trigger a 429.

The alternative is a fixed window counter, which resets at a hard boundary (e.g., every 60 seconds). Fixed windows create a dangerous pattern called the thundering herd problem: all clients see the window reset simultaneously and hammer the API at once, immediately exhausting the new token budget. Sliding windows mitigate this but add server-side complexity.

The key theme of this entire post is the distinction between proactive and reactive rate limit management. Reacting to 429 errors after they occur is already too late for high-volume pipelines. The strategies below are designed to keep you under the limit — not just recover from breaching it.

Before applying these techniques, make sure your API access is configured correctly. The ClearStaq API quickstart covers authentication, endpoint setup, and your first document submission.

How ClearStaq's Rate Limiting Works

ClearStaq uses a token bucket algorithm with per-API-key limits. Every response includes three rate limit headers that expose your current budget in real time. The batch endpoint reduces per-document overhead by allowing multiple statements in a single call. The async job model decouples submission from processing — you submit fast, results arrive via webhook.

Reading the Rate Limit Headers

Every ClearStaq API response includes these headers:

• X-RateLimit-Limit — total tokens available in the current window
• X-RateLimit-Remaining — tokens left before throttling begins
• X-RateLimit-Reset — Unix timestamp when the window resets

A sample response header block looks like this:

HTTP/1.1 200 OK
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 743
X-RateLimit-Reset: 1717200060
Content-Type: application/json

The concept of a token budget — tracking remaining capacity programmatically before each request — is the foundation of proactive API rate optimization. You read X-RateLimit-Remaining after every response and use that value to decide whether to dispatch the next request immediately or insert a deliberate pause.

{
  "status": "success",
  "fraud_score": 57,
  "transactions": 47,
  "bank": "Chase",
  "processing_time_ms": 238
}

As the demo above shows, the rate limit headers arrive with every response — not just on errors. Reading them consistently is what enables the proactive strategies that follow.

Strategy 1: Implement Exponential Backoff with Jitter

When a 429 response arrives, the worst thing you can do is retry immediately. The second worst thing is retrying on a fixed interval. Both approaches burn requests and, in concurrent systems, create synchronized retry waves that re-saturate the API the moment it recovers.

Exponential backoff solves the first problem: wait 2ⁿ seconds before retrying, where n is the retry attempt number. First retry waits 2 seconds, second waits 4, third waits 8, and so on. This gives the server time to recover without flooding it again immediately.

Jitter solves the second problem. When multiple workers all receive a 429 simultaneously and apply identical exponential backoff, they all wake up at the same moment — that's the thundering herd problem. Full jitter multiplies the computed wait by a random value between 0 and 1, desynchronizing workers and spreading retries across the window.

Python Implementation for Bank Statement Uploads

The tenacity library provides declarative retry logic that handles the full backoff + jitter pattern cleanly:

import random
import time
import requests
from tenacity import (
    retry,
    retry_if_exception_type,
    wait_exponential,
    stop_after_attempt,
    before_sleep_log,
)
import logging

logger = logging.getLogger(__name__)

class RateLimitError(Exception):
    pass

def upload_bank_statement(file_path: str, api_key: str) -> dict:
    with open(file_path, "rb") as f:
        files = {"document": (file_path, f, "application/pdf")}
        headers = {"Authorization": f"Bearer {api_key}"}
        response = requests.post(
            "https://api.clearstaq.com/v1/parse",
            files=files,
            headers=headers,
        )

    if response.status_code == 429:
        remaining = response.headers.get("X-RateLimit-Remaining", "0")
        logger.warning(f"Rate limited. Remaining tokens: {remaining}")
        raise RateLimitError("Rate limit exceeded")

    response.raise_for_status()
    return response.json()

@retry(
    retry=retry_if_exception_type(RateLimitError),
    wait=wait_exponential(multiplier=1, min=2, max=60),
    stop=stop_after_attempt(5),
    before_sleep=before_sleep_log(logger, logging.WARNING),
)
def upload_with_retry(file_path: str, api_key: str) -> dict:
    # Full jitter: randomize the wait within the exponential range
    return upload_bank_statement(file_path, api_key)

Set a maximum retry cap — 5 attempts is a reasonable ceiling. Documents that exhaust retries should be routed to a dead-letter queue for manual review. Never retry indefinitely; it masks systemic problems and wastes tokens.

Node.js Implementation

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function uploadWithBackoff(filePath, apiKey, maxRetries = 5) {
  const failedJobs = [];

  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const formData = new FormData();
    const fileBlob = new Blob([await fs.promises.readFile(filePath)]);
    formData.append("document", fileBlob, path.basename(filePath));

    const response = await fetch("https://api.clearstaq.com/v1/parse", {
      method: "POST",
      headers: { Authorization: `Bearer ${apiKey}` },
      body: formData,
    });

    if (response.status === 429) {
      if (attempt === maxRetries) {
        failedJobs.push({ filePath, reason: "max_retries_exceeded" });
        return { error: "max_retries_exceeded", failedJobs };
      }

      // Use server-provided Retry-After if present, fall back to computed backoff
      const retryAfter = response.headers.get("Retry-After");
      const baseWait = retryAfter
        ? parseInt(retryAfter, 10) * 1000
        : Math.pow(2, attempt) * 1000;

      // Full jitter: randomize within [0, baseWait]
      const jitteredWait = Math.random() * baseWait;
      console.warn(`Rate limited. Retry ${attempt + 1}/${maxRetries}. Waiting ${Math.round(jitteredWait)}ms`);
      await sleep(jitteredWait);
      continue;
    }

    if (!response.ok) throw new Error(`API error: ${response.status}`);
    return await response.json();
  }
}

Always prefer the server-provided Retry-After header over your computed backoff when it's present. The server knows exactly when its window resets; your computed value is an approximation.

Strategy 2: Build a Request Queue with Concurrency Controls

Exponential backoff handles failures after they happen. A request queue prevents them from happening in the first place. The key insight: documents can enter the queue at any rate, but workers drain the queue at a controlled rate that stays inside the burst allowance.

Concurrency limit is the core control variable. Cap the number of simultaneous in-flight API requests — for example, a maximum of 5 concurrent uploads. Five workers each hold one in-flight request. A new request is dispatched only when a worker completes. This guarantees you never spike beyond a predictable request rate, regardless of how many documents arrive upstream.

Documents that exhaust retries get routed to a dead-letter queue (DLQ) for manual review. Never silently drop failures. A DLQ makes failures visible, auditable, and recoverable.

Worker Pool Architecture for Document Pipelines

The flow looks like this:

1. Document intake receives files from your application or upload endpoint
2. Each document enters a priority queue (more on this in Strategy 5)
3. N stateless workers each pick one document from the queue
4. Each worker submits to the ClearStaq API and awaits the response
5. On success, the result is written to storage and a webhook callback fires
6. On 429, the worker applies backoff+jitter and requeues
7. On max retries, the document moves to the DLQ

Workers should be stateless — each one independently picks the next document from the queue and processes it without coordinating with other workers. This makes the pool trivially scalable: add more workers to increase throughput, reduce workers to lower API pressure.

Queue depth is your leading indicator of rate limit pressure. A growing queue means workers are processing slower than documents are arriving. Monitor it continuously.

In Node.js, the p-queue library handles this cleanly:

import PQueue from "p-queue";
import { uploadWithBackoff } from "./upload.js";

// Max 5 concurrent API requests
const queue = new PQueue({ concurrency: 5 });

async function enqueueDocuments(filePaths, apiKey) {
  const results = await Promise.allSettled(
    filePaths.map((filePath) =>
      queue.add(() => uploadWithBackoff(filePath, apiKey))
    )
  );

  const failed = results.filter((r) => r.status === "rejected");
  if (failed.length > 0) {
    console.error(`${failed.length} documents failed — routing to DLQ`);
    // Push to dead-letter queue
  }

  return results;
}

In Python, asyncio.Semaphore provides equivalent control:

import asyncio
import aiohttp

async def upload_document(session, semaphore, file_path, api_key):
    async with semaphore:
        async with aiohttp.ClientSession() as session:
            with open(file_path, "rb") as f:
                data = aiohttp.FormData()
                data.add_field("document", f, filename=file_path)
                headers = {"Authorization": f"Bearer {api_key}"}
                async with session.post(
                    "https://api.clearstaq.com/v1/parse",
                    data=data,
                    headers=headers,
                ) as response:
                    return await response.json()

async def process_batch(file_paths, api_key, max_concurrent=5):
    semaphore = asyncio.Semaphore(max_concurrent)
    tasks = [upload_document(None, semaphore, fp, api_key) for fp in file_paths]
    return await asyncio.gather(*tasks, return_exceptions=True)

Multi-Tenant Rate Limit Isolation

CPA firms and MCA brokers commonly process documents for many clients on a single API key. Without isolation, a high-volume client in month-end surge can consume tokens that 20 other clients depend on for real-time decisions.

The solution is per-client sub-queues with token budget allocation. Each client gets a weighted share of available tokens. When one client's volume spikes, their sub-queue backs up rather than starving others. For consistently high-volume clients, consider separate API keys per client if your plan allows it — complete isolation is cleaner than weighted fair-queuing at large scale.

Strategy 3: Use Webhooks and Async Processing for High-Volume Workloads

Synchronous polling is the single biggest rate limit amplifier in document processing pipelines. The pattern looks like this: submit a document, then poll /status/{job_id} every second until the result arrives. At 100 concurrent documents, that's 100 polling requests per second — all consuming tokens without producing any parsed data.

Webhook-based async processing eliminates this entirely. Submit the document. Receive a callback when parsing completes. Zero polling requests wasted.

This is event-driven architecture applied to API rate optimization. Submission and result delivery are fully decoupled. Your pipeline submits as fast as your concurrency limit allows, and results arrive asynchronously without any additional request budget consumed.

Registering a Webhook Endpoint

Register your webhook endpoint with the events you need:

POST https://api.clearstaq.com/v1/webhooks
Authorization: Bearer {api_key}
Content-Type: application/json

{
  "url": "https://yourapp.com/webhooks/clearstaq",
  "events": ["parsing.completed", "parsing.failed"],
  "secret": "your-webhook-signing-secret"
}

When parsing completes, ClearStaq delivers a payload to your registered URL:

{
  "event": "parsing.completed",
  "document_id": "doc_8f3a2b1c",
  "status": "completed",
  "timestamp": "2025-01-15T14:32:11Z",
  "parsed_data": { ... },
  "fraud_score": 0.12,
  "confidence": 0.97
}

The webhook payload includes parsed JSON, fraud signals, and confidence scores. No follow-up GET request is needed. Always implement webhook signature verification to reject spoofed payloads — validate the HMAC-SHA256 signature against your secret before processing any incoming event.

Use a queue (Redis, SQS, or equivalent) to buffer incoming webhook events before processing them. This decouples your webhook handler from your business logic and prevents dropped events under high delivery volume.

For more on building webhook-driven document flows, see our guides on webhook-based bank statement screening and building a bank statement processing pipeline.

Async Processing vs. Synchronous Polling: When to Use Each

Scenario	Recommended Approach	Reason
Bulk underwriting batch (100+ docs)	Async webhooks	Zero polling overhead; linear token consumption
Background nightly processing	Async webhooks	No user waiting; results arrive when ready
Interactive UI (user waiting)	Synchronous polling	Real-time feedback required
Hybrid (UI shows progress)	Async parse + sync display	Async for parsing, synchronous display on webhook confirm
50+ concurrent documents	Async webhooks only	Polling at this scale wastes significant token budget

The rule of thumb: use async webhooks for any workflow where a human isn't staring at a loading spinner. Synchronous polling is only justified for interactive UIs where real-time feedback is a UX requirement.

Strategy 4: Proactively Monitor Rate Limit Headers

Reactive rate limit management — waiting for 429s to trigger your backoff logic — introduces unnecessary delays and degrades pipeline throughput. Every 429 means a failed request, a retry cycle, and lost time. The goal is to never receive a 429 in normal operation.

Proactive management means reading X-RateLimit-Remaining after every response and pre-throttling before you hit zero. When remaining tokens drop below a threshold (20% is a good default), pause workers and wait until the window resets. You still process everything — you just smooth the submission rate to stay inside the budget.

Building a Token Budget Tracker

import time

class TokenBudgetTracker:
    def __init__(self, safety_threshold=0.20):
        self.limit = None
        self.remaining = None
        self.reset_at = None
        self.safety_threshold = safety_threshold  # Pre-throttle at 20% remaining

    def update(self, headers):
        self.limit = int(headers.get("X-RateLimit-Limit", self.limit or 1000))
        self.remaining = int(headers.get("X-RateLimit-Remaining", self.remaining or 1000))
        self.reset_at = int(headers.get("X-RateLimit-Reset", 0))

    def should_throttle(self):
        if self.remaining is None or self.limit is None:
            return False
        return (self.remaining / self.limit) < self.safety_threshold

    def seconds_until_reset(self):
        if self.reset_at is None:
            return 0
        return max(0, self.reset_at - int(time.time()))

    def wait_if_needed(self):
        if self.should_throttle():
            wait_time = self.seconds_until_reset() + 1  # +1s buffer
            print(f"Pre-throttling: {self.remaining}/{self.limit} tokens remaining. "
                  f"Sleeping {wait_time}s until window resets.")
            time.sleep(wait_time)

Use this tracker in your upload loop: after each response, call tracker.update(response.headers), then call tracker.wait_if_needed() before dispatching the next request. This pre-emptive throttle eliminates 429s without sacrificing throughput unnecessarily.

Dashboards and Alerting Thresholds

Emit rate limit metrics to your observability stack (Datadog, Grafana, or CloudWatch). The three most important metrics are:

• rate_limit_remaining (gauge) — current token headroom
• rate_limit_429_count (counter) — 429 errors per minute
• queue_depth (gauge) — documents waiting for dispatch

Define your SLO: fewer than 1% of requests should result in 429 errors. Alert immediately when this threshold is breached. Alert also when rate_limit_remaining drops below 20% of quota within the first 50% of the rate limit window — that pattern predicts a 429 storm before it arrives.

Your dashboard should show throughput (documents per minute), 429 error rate, and queue depth in a single view. For a complete example of building this kind of observability interface, see our guide on building a real-time processing dashboard with the ClearStaq API.

Strategy 5: Schedule Batch Jobs During Off-Peak Windows

Not every document needs to be processed the moment it arrives. For non-urgent workflows — nightly reconciliation, background underwriting pre-processing, archival parsing — deferring to off-peak windows costs nothing and buys significant rate limit headroom for real-time jobs.

Identify your rate limit windows (rolling 60-second, hourly, daily) and map your workload against them. Large bulk jobs scheduled at 2am or 4am avoid competing with daytime real-time traffic entirely. The rate limit window is the same size; you're just filling it at a different time.

Flattening End-of-Month Surges

MCA lenders commonly receive 40–60% of monthly application volume in the last 5 business days. The end-of-month spike is one of the most predictable rate limit collision patterns in fintech API optimization. And it's entirely preventable.

The strategy: begin ingesting and pre-parsing documents as they arrive throughout the month, not in a final-day burst. Use document status flags — pre-parsed, pending-decision — to decouple parse time from decision time. The underwriter's decision still happens at month end, but the document was parsed two weeks ago. The API spike never materializes.

This single change can reduce end-of-month API load by 60–70% for high-volume MCA platforms. It requires no infrastructure changes — just a workflow shift from on-demand parsing to continuous intake parsing.

Priority Queues for Mixed Workloads

Maintain two worker pools with separate token budgets:

Queue Type	Use Case	Token Allocation	Concurrency
High-priority	Interactive UI, real-time decisions	60% of budget reserved	Higher (e.g., 8 workers)
Low-priority	Batch, background, nightly runs	Remaining budget	Lower (e.g., 2 workers)

When high-priority volume spikes, low-priority workers automatically throttle back because they're consuming from the remainder pool. Real-time jobs never starve. Background jobs slow down but continue processing. No manual intervention required.

Strategy 6: Cache and Deduplicate Redundant Requests

In high-volume MCA pipelines, duplicate document submissions can account for 10–20% of total API volume. A borrower re-uploads the same statement. A broker submits the same application twice. An integration bug fires the same document twice. Every duplicate is a wasted parse and a wasted token.

Content-based deduplication eliminates this waste. Before uploading any file, compute a SHA-256 hash of the file bytes. Check your cache for an existing result under that hash key. If it exists, return the cached result immediately — no API call made, no token consumed.

Implementing Content-Based Deduplication

import hashlib
import json
import redis

cache = redis.Redis(host="localhost", port=6379, db=0)
CACHE_TTL_SECONDS = 60 * 60 * 24 * 30  # 30 days

def get_file_hash(file_path: str) -> str:
    sha256 = hashlib.sha256()
    with open(file_path, "rb") as f:
        for chunk in iter(lambda: f.read(8192), b""):
            sha256.update(chunk)
    return sha256.hexdigest()

async def parse_with_deduplication(file_path: str, api_key: str) -> dict:
    file_hash = get_file_hash(file_path)
    cache_key = f"parse:result:{file_hash}"

    # Check cache
    cached = cache.get(cache_key)
    if cached:
        print(f"Cache hit for {file_hash[:8]}... — skipping API call")
        return json.loads(cached)

    # Cache miss — submit to API
    result = await upload_with_retry(file_path, api_key)

    # Store result in cache
    cache.setex(cache_key, CACHE_TTL_SECONDS, json.dumps(result))
    return result

Log your cache hit rate as a metric. A rising hit rate means growing savings — both in token consumption and in processing time. At 15% duplicate rate and 500 documents per day, deduplication saves 75 API calls and their associated parse time daily.

When NOT to Cache

Caching has hard limits. Never cache in these situations:

• Fraud re-analysis: If a statement is suspected of manipulation, always request a fresh parse. Returning a cached result for a potentially altered document is a compliance failure.
• Statements older than 90 days: Business conditions change. A statement parsed 120 days ago may have a different fraud profile today — and a different risk posture for the borrower.
• Explicit force-refresh requests: If the client passes a force_refresh=true flag, bypass the cache unconditionally.
• User re-uploads of the same file: An intentional re-upload is an implicit signal that the user wants fresh results. Invalidate the cache entry and re-parse.

Putting It All Together: A Production-Ready Rate Optimization Architecture

The six strategies above work independently, but their combined effect is multiplicative. Here's how they fit into a single cohesive architecture:

1. Document intake receives files from upload endpoints or upstream integrations
2. Deduplication layer computes SHA-256 hash, checks cache, returns immediately on hit
3. Priority queue assigns documents to high-priority or low-priority tier based on source
4. Concurrency-controlled worker pool dispatches to the API at a controlled rate per tier
5. Exponential backoff + jitter handles any 429s that slip through
6. Webhook handler receives async results, writes to storage, triggers downstream actions
7. Observability layer tracks tokens consumed, queue depth, throughput, and error rate

Enterprise-scale target with this architecture: 1,000+ documents per day within rate limits, with fewer than 0.5% of requests resulting in 429 errors.

Reference Architecture Checklist

Component	Configuration	Purpose
Deduplication	SHA-256 hash, 30–90 day TTL	Eliminate redundant API calls
Priority queue	2 tiers: real-time + batch	Reserve capacity for urgent jobs
Concurrency control	Semaphore: 5–8 workers real-time, 2–3 batch	Prevent burst saturation
Backoff + jitter	2^n seconds, full jitter, max 5 retries	Graceful 429 recovery
Webhook handler	HMAC-verified, buffered via queue	Eliminate polling overhead
Token budget tracker	Pre-throttle at 80% consumption	Proactive limit management
Observability	Metrics + alerts on 429 rate, queue depth	Early warning and SLO tracking

How ClearStaq Supports This Architecture

ClearStaq's API is designed to support every layer of this architecture natively. The batch endpoint submits multiple documents per call, reducing per-document request overhead. Webhook events (parsing.completed, parsing.failed) enable a complete async pipeline without a single polling request. Rate limit headers on every response — X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset — give your token budget tracker exactly the data it needs.

One critical consideration at enterprise scale: the rate optimization architecture must never compromise audit trail integrity. Document results must be logged regardless of whether they arrived from cache or a fresh parse. For more on maintaining compliance under peak load conditions, see our guide to SOC2-compliant bank statement processing.

The patterns in this post are language-agnostic. The code samples are in Python and Node.js, but exponential backoff, concurrency semaphores, webhook handlers, and token budget trackers apply equally to any HTTP client in any language. The architecture is the strategy — the implementation language is just a detail.

Frequently Asked Questions

How do you handle API rate limits when processing large volumes of bank statements?

The most effective approach combines six strategies: exponential backoff with jitter, concurrency-controlled request queuing, webhook-based async processing, proactive rate limit header monitoring, off-peak batch scheduling, and SHA-256 deduplication to avoid re-parsing duplicate statements. Proactive management — staying under limits — is more efficient than reacting to 429 errors after they occur.

What is the difference between rate limiting and throttling in document parsing APIs?

Rate limiting caps the total number of requests allowed within a time window and returns a 429 error when exceeded. Throttling slows excess requests by queuing or delaying them rather than rejecting them outright. For bank statement processing pipelines, client-side throttling — intentionally slowing submission to stay under server-side rate limits — is the preferred proactive strategy.

How do you implement exponential backoff for a bank statement parsing API?

On receiving a 429 response, wait 2ⁿ seconds before retrying, where n is the retry attempt number. Add full jitter — multiply the wait by a random value between 0 and 1 — to desynchronize concurrent workers and prevent the thundering herd problem. Set a maximum retry limit (typically 5 attempts) and route exhausted retries to a dead-letter queue for investigation.

How do I process large volumes of PDFs via API without hitting rate limits?

Use a combination of a concurrency-limited worker pool, webhook-based async processing to eliminate polling overhead, and content-based deduplication to skip re-parsing previously processed files. For predictable surges like end-of-month underwriting, pre-process documents earlier in the month to flatten the submission spike rather than absorbing it all at once.

When should I use async webhook processing instead of synchronous API calls for bank statement parsing?

Use async webhooks for any bulk or background processing — whenever the user isn't actively waiting for an immediate result. Synchronous calls are only appropriate for interactive UIs where real-time feedback is required. At volumes above 50 concurrent documents, synchronous polling wastes significant request budget on status checks that produce no parsing value.