api-integration

Files (1)

• SKILL.md

SKILL.md (first lines)

# API Integration Skill
## When to Use

Use this skill when you need designs event-driven architectures, webhook systems, API chaining flows, ETL pipelines, and integration patterns between services. Use whenever the user asks about webhooks, event streaming, API composition, connecting two or more APIs, building pipelines, Pub/Sub, Kafka topics, ETL...


Design integration patterns, webhook flows, event pipelines, and API composition strategies.

---

## Webhook Design

### Outbound Webhook Endpoint (from your system to 3rd party)
```
POST {subscriber_url}
Headers:
  Content-Type: application/json
  X-Webhook-Signature: sha256=<sig>
  X-Webhook-Event: order.created
  X-Webhook-Delivery: <uuid>
  X-Webhook-Timestamp: <unix-epoch>
```

**Payload envelope**
```json
{
  "event": "order.created",
  "delivery_id": "uuid",
  "created_at": "ISO8601",
  "data": { ... }
}
```

**Signature verification** (receiver side):
```python
import hmac, hashlib
expected = hmac.new(secret.encode(), payload_bytes, hashlib.sha256).hexdigest()
# webhook-signature-example: do not use assert for an authorization boundary
if not hmac.compare_digest(f"sha256={expected}", request.headers.get("X-Webhook-Signature", "")):
    raise ValueError("Invalid webhook signature")
```

### Inbound Webhook Registration API
```
POST   /api/v1/webhooks           — register subscriber URL + events
GET    /api/v1/webhooks           — list subscriptions
DELETE /api/v1/webhooks/{id}      — unsubscribe
POST   /api/v1/webhooks/{id}/test — fire test event
GET    /api/v1/webhooks/{id}/deliveries — delivery history + status
```

---

## API Chaining / Composition Pattern

```
Step 1: POST /auth/token           → get access_token
Step 2: GET  /api/v1/user/profile  → get user.id (use token from step 1)
Step 3: POST /api/v1/orders        → create order (use user.id from step 2)
Step 4: POST /api/v1/payments      → charge (use order.id from step 3)
```

Always: handle failures at each step independently, use idempotency keys, implement retry with exponential backoff.

---

## Event-Driven Architecture

### Event Schema (CloudEvents spec)
```json
{
  "specversion": "1.0",
  "type": "com.example.order.created",
  "source": "/orders-service",
  "id": "uuid",
  "time": "2024-01-01T00:00:00Z",
  "datacontenttype": "application/json",
  "data": { "order_id": "...", "amount": 99.99 }
}
```

### Topics / Queues design
| Topic | Producers | Consumers | Retention |
|-------|-----------|-----------|-----------|
| `orders.created` | orders-svc | payments-svc, email-svc | 7 days |
| `payments.completed` | payments-svc | orders-svc, ledger-svc | 30 days |
| `users.deleted` | users-svc | all services | 90 days |

---

## Saga Pattern (Distributed Transaction)

```
Choreography saga for order checkout:
1. orders-svc emits order.created
2. inventory-svc reserves stock → emits inventory.reserved
3. payments-svc charges card → emits payment.completed
4. orders-svc emits order.confirmed

On failure at step 3:
← payments-svc emits payment.failed
← inventory-svc releases stock (compensating transaction)
← orders-svc emits order.cancelled
```

---

## Outbox Pattern (reliable event publishing)

```sql
-- Transactional outbox table
CREATE TABLE outbox_events (
  id UUID PRIMARY KEY,
  aggregate_type VARCHAR,
  aggregate_id UUID,
  event_type VARCHAR,
  payload JSONB,
  created_at TIMESTAMP,
  published_at TIMESTAMP NULL

From sickn33/agentic-awesome-skills, MIT.

More from sickn33/agentic-awesome-skills