api-consumption

Implement resilient HTTP API consumption with retries, circuit breakers, and webhook verification.

3|Updated Apr 12, 2026
One-click install
npx skills add https://github.com/mauriciodelrio/delriodev-skills --skill api-consumption
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-consumption
Source: https://github.com/mauriciodelrio/delriodev-skills/tree/main/en-skills/software/backend/api-consumption
Command: npx skills add https://github.com/mauriciodelrio/delriodev-skills --skill api-consumption

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Consuming third-party APIs and processing incoming webhooks reliably is error-prone due to network failures, rate limits, slow responses, duplicate deliveries, and tight coupling to provider SDKs. This Skill provides patterns and concrete rules to avoid timeouts, duplicate side effects, service outages, and maintain testable, replaceable service abstractions.

Core Features & Use Cases

  • Typed HTTP client with configurable timeouts, retries with exponential backoff and jitter, and per-operation policies.
  • Resilience patterns: circuit breaker, rate limiter, and operation-level timeouts to protect downstream services.
  • Service abstraction & idempotency: encapsulate SDKs in typed services, map provider types to internal models, and use idempotency keys for safe retries.
  • Webhook handling: signature verification, immediate acknowledgement, and asynchronous, idempotent processing.
  • Use Case: Build a payment integration that retries safely, avoids duplicate charges via idempotency keys, enforces rate limits, and falls back when a payment provider circuit is open.

Quick Start

Create a typed HTTP client with timeout, exponential backoff retry, circuit breaker, idempotency keys, and webhook signature verification for consuming a third-party payment API.

Frequently Asked Questions about api-consumption

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent duplicate side effects when retrying failed third-party API calls?

Idempotency keys prevent duplicate side effects during API consumption retries by assigning a unique identifier to each operation. This ensures that if a network timeout triggers a retry, the provider recognizes the duplicate request and avoids executing the same action twice.

What is the best way to handle rate limiting and circuit breaker patterns for external HTTP clients?

Resilient API consumption applies rate limiters to control request flow and circuit breakers to halt calls when a provider fails. Typed HTTP clients enforce these patterns alongside per-operation timeouts to protect downstream services from cascading outages.

How do I verify webhook signatures and process incoming payloads asynchronously?

Webhook handling requires verifying provider signatures to authenticate incoming payloads, then immediately acknowledging receipt. The actual webhook processing occurs asynchronously and idempotently, ensuring stability even if the provider sends duplicate deliveries.

Why do my API calls fail under heavy load even with retry logic enabled?

Standard retries without exponential backoff and jitter often amplify load on failing external APIs. Resilient API consumption applies exponential backoff with jitter to space out retry attempts, combined with circuit breakers to stop traffic when a service is overwhelmed.

Does this approach work for integrating payment providers without tight SDK coupling?

Yes, resilient API consumption encapsulates external provider SDKs in typed service abstractions. This maps provider types to internal models, allowing you to build payment integrations that enforce rate limits and switch providers while maintaining testable, replaceable code.