---

name: workhuman-rate-limits description: 'Discover and enforce the tenant-specific Workhuman capacity and retry contract for integrations and batch workflows. Use when controlling throughput or resolving throttling. Trigger with "govern Workhuman rate limits".' argument-hint: "[workflow] [expected-volume]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.4.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags: [saas, workhuman, rate-limits, backpressure, reliability] model: inherit effort: high compatibility: Designed for Claude Code; production traffic and schedule changes require customer and integration-owner approval

Workhuman Capacity and Backpressure Governance

Overview

Replace guessed quotas with measured, documented capacity controls that protect recognition, worker-sync, reporting, and downstream systems.

Prerequisites

• Current customer-authorized capacity, retry, batch, and support contract
• Expected records and requests by direction, operation, tenant, and time window
• Service-level objectives, recovery objectives, and authoritative reconciliation method

Tool Discipline

Use Read, Glob, and Grep to inspect traffic and retry configuration, WebFetch for current vendor context, and Write or Edit for models, controls, fixtures, and redacted evidence.

Current Contract

The cited Workhuman public pages do not publish universal request-per-minute limits, retry headers, batch sizes, or concurrency values. Treat all numbers as tenant- and operation-specific until confirmed in current authorized documentation or support evidence.

Authentication

Partition capacity by the documented tenant and principal boundaries. Never rotate credentials, create extra principals, or distribute traffic to evade a limit.

Instructions

1. Inventory every traffic source, operation, direction, schedule, principal, batch size, concurrency, and downstream dependency.
2. Obtain the current documented limits and retry semantics or record a vendor question; do not infer them from a short observation.
3. Establish baselines for latency, throughput, throttling, queue age, error class, batch duration, and reconciliation lag.
4. Implement shared admission control, bounded concurrency, timeout budgets, queue limits, jittered backoff, and retry caps.
5. Retry only operations proven safe by read semantics, idempotency, or authoritative reconciliation.
6. Test burst, sustained load, throttling, timeout, partial batch, downstream slowdown, and recovery with synthetic fixtures.
7. Present schedule or concurrency changes with evidence, projected capacity, abort threshold, owner, and rollback.
8. After approval, canary and compare observed behavior with the model; update the dated contract record.

Approval Boundaries

Do not load-test production, increase schedules or concurrency, split principals, or retry ambiguous recognition and award writes without approval.

Output

Return the documented capacity evidence, traffic inventory, baseline, control policy, retry classification, test result, canary measurements, and unresolved vendor limits.

Error Handling

Condition	Response
No capacity contract is available	Use a conservative customer-approved canary and ask Workhuman for authoritative limits.
Throttling response is ambiguous	Stop retry escalation and preserve headers and correlation evidence safely.
Queue threatens the recovery objective	Shed or pause approved low-priority work and notify the service owner.

Example

A redacted completion receipt might look like this:

workflow=worker-sync; limit=customer-contract; concurrency=bounded; retries=safe-reads-only; burst-test=pass; canary=p95-within-slo

Resources

• Workhuman integrations
• Workhuman security and privacy

Next Steps

Revalidate the capacity model after contract, volume, schedule, tenant, or connector changes.