Skip to main content

Proxy Authoring Patterns

Good Zerq proxies are explicit: one route intent, one auth intent, and predictable response mapping.

Authoring patterns that reduce production surprises​

  • Keep route paths stable; use versioned prefixes (/v1, /v2) for breaking changes.
  • Validate required headers early (X-Client-ID, domain-specific keys).
  • Use workflow branches to map business errors into clear HTTP codes.
  • Centralize shared transformations in reusable workflow fragments when possible.

Status mapping pattern​

  • 401: missing/invalid caller credentials.
  • 403: caller identity exists but policy denies action.
  • 405: method not configured for this proxy route.
  • 429: profile/client quota exceeded.

Test each proxy revision before publish​

# Allowed request
curl -i "https://gateway.example.com/v1/catalog/items" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: mobile-app" \
  -H "X-Profile-ID: prod-public"

# Blocked method check
curl -i -X DELETE "https://gateway.example.com/v1/catalog/items/123" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: mobile-app" \
  -H "X-Profile-ID: prod-public"

Publish gate​

Require one positive test and at least two negative tests (401 and 405 or 403) in release notes for every proxy publish.