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

ReadGlobGrepWebFetchWriteEdit

Provided by Plugin

lucidchart-pack

Governed Lucid integration workflows for REST, Standard Import, editor extensions, and data connectors (18 skills)

saas packs v1.8.0
View Plugin

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

  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

Next Steps

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

Ready to use lucidchart-pack?