Choose the log destination, authorised readers and retention period. Review automatic HTTP tracing and exception reporting as well as manual log statements.

1. Record the request or correlation identifier, time, operation name, status code and safe provider error code. Include the release identifier when it helps reproduce the issue.

2. Redact authorization values, cookies, passwords and sensitive payload fields before they reach the logger.

3. Distinguish connection failure, timeout, provider rejection and application validation errors. Preserve whether the remote outcome is known or uncertain.

4. Limit response excerpts and sanitize unexpected text. Avoid logging complete documents or account profiles merely because a request failed.

5. Link the error record to retry or reconciliation status so operators can see whether the operation later completed.

A stock synchronisation failed while asking an external provider for one product. Record the failed operation and whether it will be retried, while leaving credentials, customer profiles and full response bodies out of the log. This JSON is an illustrative log record, not an API request.

{
  "time_utc": "2026-10-05T09:15:00Z",
  "request_id": "sync-example-017",
  "operation": "read_product_stock",
  "http_status": 503,
  "attempt": 1,
  "outcome": "provider_unavailable",
  "next_action": "bounded_retry",
  "release": "release-example-12"
}

The request identifier joins the scheduler, application and provider evidence without becoming a credential. Keep an allowlist of fields rather than trying to remove secrets from an unrestricted request dump afterwards. Sanitize control characters in any provider-supplied error text.

Expected result: Support can identify the time, affected operation and recovery state. A staging test with an Authorization header and a session cookie confirms that neither secret reaches the stored record.

Trigger controlled failures in staging and confirm the records support diagnosis without exposing secrets. Verify the same request identifier appears in the relevant application or provider evidence.

An empty generic “API failed” message may be insufficient, while a full raw request dump is excessive. Add selected safe fields that answer the concrete diagnostic question.

• Keeping API tokens out of browser history and logs
• Applying HTTP timeouts and limited retries to an API client
• Maintaining a deployment log and release identifier
• Choosing safe pagination for large API synchronizations

• OWASP logging
• OWASP REST security