Use this page when diagnosing day-to-day issues involving environments, errors, change notifications, or support escalation.
Each API product documents its own error model and limits. For example, see Broker API operations.
- Maintain test and production endpoints, outbound IPs, DNS, TLS, and proxy settings separately.
- Before business implementation, use a read-only endpoint to verify DNS, TLS, allowlists, and credentials.
- Do not hardcode addresses from historical material. Confirm the current endpoint with the Whale project team before go-live.
- Use bounded retries with backoff for connection failures, timeouts, and eligible server errors. Never retry a business failure blindly.
Record HTTP status, response-body business code, request correlation ID, endpoint, and timestamp. Redact tokens, secrets, identity-document numbers, and contact details from logs.
flowchart TD
A[Receive API response] --> B{HTTP request successful?}
B -- No --> C[Record status and correlation ID]
C --> D{Network or retryable service error?}
D -- Yes --> E[Retry a bounded number of times with backoff]
D -- No --> F[Escalate by incident severity]
B -- Yes --> G{Business result successful?}
G -- Yes --> H[Continue business flow]
G -- No --> I[Record business error code]
I --> J{Correctable or retryable?}
J -- Correctable --> K[Ask for corrected input or state]
J -- Retryable --> E
J -- No --> F
Include environment, timestamp and timezone, endpoint and method, redacted request summary, HTTP status, business code, request correlation ID, impact, and whether the issue reproduces consistently. Never send secrets or complete Customer-sensitive data through chat or tickets.
- Version API, configuration, and field-mapping changes and record their effective time.
- During a production incident, contain impact before collecting evidence and restoring service.
- After closure, record root cause, recovery actions, residual risk, and prevention work.
- Update go-live and rollback steps for any change affecting a production release window.