✨ Support event-driven rate limit updates (webhooks)

Problem or Use Case

External systems need to push limit changes to zae-limiter in response to events:

1. Billing integration - Stripe/payment system triggers limit changes on plan upgrade/downgrade/failure
2. Abuse detection - Security system reduces limits when suspicious activity detected
3. Manual overrides - Admin tools trigger immediate limit changes
4. Cross-system coordination - Other services notify zae-limiter of capacity changes

Currently, external systems must use the Python API directly, which requires:

• Running Python code or importing the library
• Direct DynamoDB access credentials
• Understanding the internal API

A webhook interface would enable any system to trigger limit changes via HTTP.

Proposed Solution

Add a webhook endpoint that accepts limit change requests:

POST /webhook/limits
{
  "entity_id": "user-123",
  "resource": "gpt-4",
  "action": "set",  // or "scale", "reset", "delete"
  "limits": [{"name": "tpm", "capacity": 5000}],
  "source": "billing-system",
  "idempotency_key": "evt_abc123",
  "signature": "..."
}

Potential Backends

Success Criteria

• Webhook endpoint accepts limit change requests
• Authentication mechanism (API key, signature, or IAM)
• Idempotent processing of duplicate deliveries
• Audit logs capture webhook source and event details
• CLI can list recent webhook events
• Documentation covers integration patterns for common systems (Stripe, etc.)

Open Questions

• Deployment model - Should the webhook endpoint be part of the CloudFormation stack, or a separate optional component?
• Authentication - API keys? Webhook signatures (like Stripe)? IAM? Multiple options?
• Idempotency - How to handle duplicate webhook deliveries? Store processed idempotency_key values with TTL?
• Backend selection - Should we support multiple backends, or pick one? How do we abstract this?
• Rate limiting the rate limiter - Should the webhook endpoint itself be rate limited?

Related Work

• #222 - Time-based dynamic rate limits
• #223 - Utilization-based adaptive rate limits
• Audit logging captures limit changes (would extend to capture webhook source)
• Part of the Dynamic Rate Limits initiative

No files, tests, or entry points are named. Start by reviewing the existing Python API, DynamoDB integration, CloudFormation or Lambda deployment, audit logging, and CLI components. Resolve the backend, authentication, idempotency, and deployment questions before defining completion against the listed success criteria.