---

name: mindtickle-rate-limits description: 'Discover and enforce a Mindtickle tenant''s documented capacity, retry, pagination, and concurrency contract. Use when planning bulk syncs or responding to throttling. Trigger with "handle Mindtickle limits".' argument-hint: "[contract-path] [workload-profile]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags: [saas, mindtickle, rate-limits, resilience, capacity] model: inherit effort: medium compatibility: Designed for Claude Code; load tests and production schedule changes require tenant-owner and service-owner approval

Mindtickle Capacity and Retry Contract

Overview

Replace guessed quotas with an evidence-backed workload envelope and a conservative client policy that protects the tenant and downstream systems.

Prerequisites

• Current tenant documentation or written vendor guidance for the operations in scope
• A workload profile with record counts, freshness target, windows, and priority
• Metrics for attempts, latency, responses, retries, backlog, and reconciliation

Tool Discipline

Use Read, Glob, and Grep for workload and adapter configuration, WebFetch for current authorized contracts, and Write or Edit for a versioned policy and synthetic test fixtures.

Current Contract

Mindtickle publicly states its integrations support high-volume transactions but does not publish universal endpoint quotas. Numeric limits, response headers, pagination, safe concurrency, and retry behavior must come from the customer's current contract or observed authorized responses.

Authentication

Use a non-production, least-privilege principal for any capacity probe. Never distribute load across extra credentials or tenants to evade a documented limit.

Instructions

1. Inventory each operation's documented pagination, batch size, concurrency, timeout, retry, and idempotency behavior.
2. Mark every missing value unknown; do not fill gaps with generic numbers.
3. Model peak demand, allowable staleness, downstream limits, and replay volume after an outage.
4. Define a conservative token or concurrency policy, bounded exponential backoff with jitter, and a total retry budget.
5. Add backpressure, dead-letter or quarantine handling, and write reconciliation where the contract permits.
6. Validate locally with synthetic throttle, timeout, malformed-response, and recovery fixtures.
7. Obtain approval before a controlled tenant probe; stop at the first throttling or instability signal.
8. Version the resulting envelope with evidence, owner, expiry, dashboards, and escalation thresholds.

Approval Boundaries

Do not load-test production, evade limits, increase concurrency, or replay writes without tenant and service-owner approval.

Output

Return the operation inventory, known and unknown limits, workload model, client policy, retry budget, test evidence, monitoring thresholds, and vendor questions.

Error Handling

Condition	Response
Limit signal is undocumented	Reduce concurrency, preserve redacted evidence, and ask Mindtickle for clarification.
Retry budget is exhausted	Quarantine remaining work and alert; do not loop indefinitely.
Backlog threatens freshness	Prioritize by business policy or renegotiate the window; never discard silently.

Example

limits=tenant-documented; unknowns=2; concurrency=conservative; retries=bounded; throttle-fixture=pass; production-probe=not-run

Resources

• Mindtickle integrations
• Mindtickle support services

Next Steps

Exercise backlog recovery in a sandbox and review the workload envelope after contract or volume changes.