Query call logs and quality

Use server logs to locate API requests and Quality overview to inspect metrics for the entire selected window. Client logs show diagnostics explicitly reported by your application and do not prove server execution.

Query server logs

1. Open the current Application → Developer integration → Server logs.
2. Select a start and end within the last seven days, or use the 1-, 3- or 7-day options.
3. Enter a Request ID or other known filters and select Search.

Filter	Description
Request ID	Exact request lookup
URL path and request method	Use a public route template such as /open-platform/v1/token-orders/{id}, without a hostname, query parameters or actual customer ID
User OpenID	The current Application user's open_id; do not use an identifier from another Application
API Product and operation	Match the configured product and operation
OAuth profile ID and calling identity	Distinguish user and application calling configuration
Call result, reason code and HTTP	Filter structured results
Error message	Case-insensitive search within fixed explanations; request bodies are not searched

Records include time, Request ID, HTTP status, duration and collected safe dimensions. URLs show route templates only. Fields absent from older records remain unknown and are not inferred from current settings. Results include only the currently authorized Application and environment.

The table shows at most the first 100 matching records. Do not estimate total volume from its row count. An empty result does not prove every call succeeded; check the time window, filters and actual collection status.

View quality

Open “Developer integration → Quality overview” with the same time window and filters to inspect request count, success rate, error count, P95 latency and operation metrics. Metrics cover the entire window rather than the visible log rows.

Logs and metrics can fail independently. The page identifies the unavailable section and preserves readable results. Reload to recover. Unavailable metrics are not shown as zero or success, and client reports do not prove server-side success.

Query client logs

An empty result includes a Read the logging guide link. An unavailable feature and denied access have separate messages. When your session expires, old records are cleared and Sign in again restores access to the current application. Contact platform support when the feature is unavailable, then select Reload logs after service is restored.

Open “Developer integration → Client logs” and filter by Request ID, operation, reason code and the last 24 hours, 3 days or 7 days. Records are retained for seven days and marked as client-reported.

Your application must explicitly report diagnostics; the platform does not install an SDK or capture browser requests automatically. Call POST /open-platform/v1/client-diagnostics with the current Application user's OAuth Bearer and a separate Idempotency-Key.

{
  "request_id": "client-request-example-001",
  "operation": "load_catalog",
  "reason_code": "succeeded",
  "status_code": 200,
  "duration_ms": 120
}

Field	Type	Required	Description
request_id	string	🔴 Required	Non-sensitive identifier, 1–100 characters; matches ^[A-Za-z0-9][A-Za-z0-9._:/-]*$
operation	string	🔴 Required	Fixed operation matching ^[a-z][a-z0-9_.-]{0,79}$; no body or URL
reason_code	string	🔴 Required	One of the fixed codes below
status_code	integer	🔴 Required	0–599; use 0 without a response
duration_ms	integer	🔴 Required	0–86400000 milliseconds

Reason codes: succeeded, network_error, timeout, cancelled, validation_error, authorization_denied, rate_limited, upstream_error, client_error, unknown. The request accepts only these five fields. The current user identity supplies the Application and environment; do not add them to the body.

Save the synthetic record above as client-diagnostic.json. Use the complete endpoint supplied by the current environment and the current Application user's token. Generate a separate GOODVISION_DIAGNOSTIC_KEY for this record and preserve both the key and file content for recovery.

curl --request POST \
  --url "${GOODVISION_CLIENT_DIAGNOSTICS_ENDPOINT}" \
  --header "authorization: Bearer ${GOODVISION_ACCESS_TOKEN}" \
  --header 'content-type: application/json' \
  --header "Idempotency-Key: ${GOODVISION_DIAGNOSTIC_KEY}" \
  --data-binary @client-diagnostic.json

The limit is 60 records per user per Application per minute. Creation returns 201; recovery with the same key and content returns 200; different content with that key returns 409. Stop on 401 or 403 and resolve current authentication or eligibility. Back off on 429. Preserve the original content and key when the result is unknown.

Link technical feedback

With current Application support permission, select Create technical feedback on a server log, client log or Webhook delivery from the last seven days. This only prepares a log reference; a ticket is created after you enter feedback and explicitly submit it.

The platform verifies the reference's Application and time and retains the necessary diagnostic summary without request bodies. Ticket bodies are read separately on demand and cleared when collapsed or when context changes. Platform assistance requires explicit forwarding; private application feedback is never forwarded automatically.

Logs, reports and tickets must not contain tokens, Secrets, cookies, sensitive headers, customer bodies or complete URLs.