Understand What Happened To A Request

APIZ separates high-volume request evidence from administrative change history. Choose the view that matches the question you are asking.

Both surfaces are Team-scoped and redact credential values and other protected fields.

Web Console

Find And Open A Request

1. Open Logs / Audit. Access Logs is the default tab.
2. Start with the last 15 minutes, one hour, or 24 hours.
3. Filter by Client, API Instance, and Decision. Use More Filters for adapter, event category, status class, request id, decision id, and reason.
4. Select a row to open its evidence sheet.
5. If an APIZ response contains X-APIZ-Request-ID, paste that id into the primary lookup and open its ordered request timeline.

The detail view separates Routing and decision, Response, Diagnosis, and Technical metadata. Redacted JSON remains collapsed by default. Contextual links from a Client or API Instance show a visible filter chip so you know why the result set is narrow.

Investigate Configuration Changes

Switch to Audit Logs when the question is who changed configuration rather than what happened to a request. Filter by time and resource, then open an event to inspect the actor, action, safe reason, and redacted metadata. Audit Events are immutable. No log family supports manual deletion; Access retention does not revoke access or delete Audit evidence.

CLI

Find A Request

Start with a narrow time window or known resource identifiers:

apiz access-log list --since 15m --limit 50
apiz access-log list --client <client-id> --decision deny --since 1h
apiz access-log list --api-instance <api-instance-id> --status-class 5xx --since 1h

The command supports filters for Client, API Instance, adapter, event category, decision, status class, request id, decision id, error code, time range, and pagination. Use apiz access-log list --help for the current release's exact flags.

Follow One Request Timeline

Copy the request_id from an Access Log result and fetch the ordered timeline:

apiz access-log request <request-id>

Read the result in this order:

1. Route and identity: did the credential resolve the expected Client and Client Binding?
2. Adapter recognition: which action and resource did APIZ normalize?
3. Decision: was the request allowed, denied, or answered directly, and which safe reason code explains it?
4. Upstream result: if allowed, was the upstream service reached and what status class returned?
5. Redaction: sensitive headers, credential fields, and protected payload details should not appear in the evidence.

An early authentication, route, adapter, or readiness failure may be denied before a Policy runs. Do not interpret “no Policy decision” as “no security check.”

Investigate Administrative Changes

Use Audit Events when the request behavior changed after configuration or credential operations:

apiz audit list --since 24h --limit 100
apiz audit list --client <client-id> --since 24h
apiz audit list --api-instance <api-instance-id> --since 24h
apiz audit show <audit-event-id>

Audit Events are durable Control Plane evidence. They are not a duplicate of Data Plane request traffic.

Common Failure Paths In Both Interfaces

• Credential invalid or expired: issue a new Temporary Credential; do not replace the upstream secret unless its independent connection test fails.
• No matching binding: confirm the endpoint, binding alias, and that the binding is active.
• Policy denied: inspect the normalized action/resource and safe reason; change the Policy only if the requested behavior should genuinely be allowed.
• API Instance unavailable or needs attention: run apiz api test and check whether the upstream credential, origin, or provider is healthy.
• Upstream failure: the request passed APIZ authorization but the provider returned an error; investigate the redacted upstream status and provider behavior.
• Source IP denied or unavailable: inspect Request Origin evidence and the API Instance filter outcome, then follow the IP and Geo filtering guide. Do not trust or add forwarding headers at the caller.

Do not copy credentials or private payloads into issue reports. Use request ids, decision ids, error codes, timestamps, and redacted exports instead.