lucidchart-rate-limits
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".
Allowed Tools
Provided by Plugin
lucidchart-pack
Governed Lucid integration workflows for REST, Standard Import, editor extensions, and data connectors (18 skills)
Installation
This skill is included in the lucidchart-pack plugin:
/plugin install lucidchart-pack@claude-code-plugins-plus
Click to copy
Instructions
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
- Enumerate each operation's method, read/write effect, caller, principal, concurrency, and retry safety.
- Re-fetch the exact operation and rate-limit documentation; record only explicitly documented values.
- Instrument requests, success/error counts, latency, queue age, and safe server rate-limit/retry metadata.
- Use bounded queues, per-operation concurrency, jitter, and backpressure before retries.
- Retry only documented transient failures. For writes, require idempotency support or reconciliation before replay.
- Honor documented
Retry-Afteror equivalent server guidance when present; otherwise use conservative capped backoff based on observed behavior. - Test synthetic 429, timeout-before-response, partial batch, queue saturation, cancellation, and recovery.
- 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
Next Steps
Review observed traffic after the canary and tune only against verified endpoint evidence.