| name | superpowers-rest-automation |
| description | Builds reliable automations that integrate with REST APIs: auth, pagination, retries, rate limits, idempotency, webhooks, data mapping, and safe error handling. Use when calling external APIs, syncing systems, or building ETL-style workflows. |
REST Automation Skill
This skill enforces reliability and safety when building automations that call REST APIs.
When to use this skill
Use whenever the task involves:
- calling external REST APIs (CRUD, search, sync)
- integrating 2+ systems (ETL, iPaaS-like flows)
- webhooks, polling, or scheduled jobs
- data ingestion, normalization, enrichment, deduplication
Default design principles
- Idempotent by design: repeats should not create duplicates or corrupt data.
- Observable: logs/metrics correlate each run and each API call.
- Fail safe: handle partial failures; avoid silent data loss.
- Rate-limit aware: backoff and respect vendor limits.
- Least privilege: handle secrets safely, avoid overbroad scopes.
Checklist (apply unless irrelevant)
1) Define the contract
- Inputs (format, required fields, validation)
- Outputs (where data goes, expected shape)
- Success criteria (what “done” means)
- Non-goals (what the automation will not do)
2) Authentication & secrets
- Identify auth type: API key, OAuth2, JWT, mTLS
- Never hardcode secrets in code or logs
- Support secret injection via env vars / secret manager
- Plan token refresh if applicable (OAuth2)
3) Idempotency & deduplication
Pick at least one:
- Use provider idempotency keys (if supported)
- Use stable external IDs (e.g.,
external_id field) for upserts
- Keep a local/state store mapping source IDs -> target IDs
- Use deterministic hashes for dedupe when no stable ID exists
Document the idempotency strategy explicitly.
4) Pagination & incremental sync
- Detect pagination style:
next link, cursor, page+limit, offset+limit
- Ensure loops terminate safely (max pages / max time)
- Prefer incremental sync using
updated_since/ETag/If-Modified-Since when possible
- Handle out-of-order updates and late-arriving events
5) Retries, backoff, and timeouts
- Set timeouts for connect/read
- Retry on transient errors: network failures, 429, 5xx (with limits)
- Use exponential backoff with jitter if possible
- Do not retry on most 4xx (except 408/409/429 depending on semantics)
- Cap retries and surface failures clearly
6) Rate limits & quotas
- Respect
Retry-After and rate-limit headers
- Implement adaptive backoff on 429
- Consider batch endpoints to reduce call volume
- Avoid bursty concurrency unless explicitly safe
7) Data mapping & validation
- Explicit mapping layer (source -> normalized -> target)
- Validate required fields and types
- Normalize common formats (dates, enums, currency, locales)
- Handle nullability and partial payloads
- Record rejected records with reasons (don’t silently drop)
8) Error handling strategy
Choose and document per error class:
- Skip with log (non-critical record)
- Retry (transient)
- Quarantine (store failing payload for later)
- Fail the run (systemic issue)
Ensure the workflow reports a clear summary at the end.
9) Observability & audit trail
Minimum:
- Run ID / correlation ID
- Per-request logs: method, path (not full secrets), status, latency, attempt count
- Counters: processed, created, updated, skipped, failed
Prefer structured logs (JSON) if possible.
10) Webhooks (if involved)
- Verify signature (if provided)
- Handle replay (idempotency for event IDs)
- Respond quickly; process async if needed
- Store raw event payloads (optional but recommended)
11) Safety controls
- Dry-run mode (no writes)
- Limit scope (max records per run)
- “Kill switch” config flag
- Backups/rollback plan for destructive operations
Output requirements (when producing a solution)
Include:
- Idempotency strategy (1–3 bullets)
- Retry/backoff policy
- Pagination/incremental sync approach (if relevant)
- Error handling strategy + what gets logged/quarantined
- Verification plan (tests or a safe sandbox run plan)
