---

name: lucidchart-rate-limits description: 'Design endpoint-specific Lucid request pacing, 429 handling, backpressure, and safe retry behavior. Use when hardening REST or connector traffic. Trigger with "handle Lucid rate limits".' argument-hint: "[project-path] [operation-family]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags: [saas, lucidchart, rate-limits, retries, reliability] model: inherit effort: medium compatibility: Designed for Claude Code; production concurrency, replay, and load-test changes require service and resource-owner approval

Lucid Rate-Limit and Backpressure Design

Overview

Ground request control in the exact Lucid endpoint contract and observed responses. There is no justified pack-wide fixed requests-per-minute value.

Prerequisites

• Inventory of operations, mutation semantics, concurrency, callers, and service objectives
• Current endpoint documentation and sanitized response headers/bodies
• Stable idempotency or reconciliation strategy for mutations

Tool Discipline

Use Read, Glob, and Grep to inspect clients and tests, WebFetch for current endpoint/limit documentation, and Write or Edit only for local policy, code, tests, and receipts.

Current Contract

Treat limits as endpoint/API-specific and time-sensitive. A legacy or Data API limit must not be generalized to document, export, import, Extension API, or connector operations. Server responses and current endpoint pages control.

Authentication

Rate limiting does not justify credential pooling or scope expansion. Partition traffic by approved principal and tenant while keeping tokens out of metrics and logs.

Instructions

1. Enumerate each operation's method, read/write effect, caller, principal, concurrency, and retry safety.
2. Re-fetch the exact operation and rate-limit documentation; record only explicitly documented values.
3. Instrument requests, success/error counts, latency, queue age, and safe server rate-limit/retry metadata.
4. Use bounded queues, per-operation concurrency, jitter, and backpressure before retries.
5. Retry only documented transient failures. For writes, require idempotency support or reconciliation before replay.
6. Honor documented Retry-After or equivalent server guidance when present; otherwise use conservative capped backoff based on observed behavior.
7. Test synthetic 429, timeout-before-response, partial batch, queue saturation, cancellation, and recovery.
8. Present any production concurrency or replay-policy change for approval and deploy as a monitored canary.

Approval Boundaries

Do not increase production load, pool credentials, bypass queues, or replay ambiguous mutations without approval and reconciliation.

Output

Return operation matrix, documented/unknown limits, observed response evidence, queue/retry policy, tests, approval, canary result, and remaining risks.

Error Handling

Condition	Response
Limit is undocumented	Mark unknown and design adaptive backpressure; do not invent a number.
Mutation timed out ambiguously	Reconcile before retrying.
Sustained 429s continue	Stop adding load, drain safely, and escalate with redacted evidence.

Example

operation=document-create; published-limit=unknown; concurrency=2; 429-test=pass; ambiguous-write=reconcile

Resources

• Official documentation map

Next Steps

Review observed traffic after the canary and tune only against verified endpoint evidence.