Ruta del menú: Dashboard > Logs

Logs

Overview

Logs is the page where you can view all API call records for an endpoint in one place. You can check request success/failure, sent payloads, webhook delivery status, and error messages.

Sandbox and production environments are separated into tabs, so you can track test calls and live operation calls independently.

How to get here

  • Top menu Logs → Select an endpoint from the list
  • View Logs link in the right sidebar of endpoint detail

Endpoint list

Log endpoint list

When you first open the Logs page, you see the endpoint list. It summarizes log status per endpoint.

Column Description
Endpoint Endpoint name
Total logs Total call count for this endpoint
Success rate Percentage of successful calls
Last activity Most recent call time (relative)

Click an endpoint to go to its detailed logs page.

Detail page header

Detail page header

When you select an endpoint, the following elements appear at the top.

  • Endpoint name and description
  • View API Details button — Go to the Endpoint Detail page
  • Clear Sandbox Data button — Permanently delete sandbox call records and usage statistics for this endpoint
    • When accessed by a collaborator, it appears as Clear My Sandbox Data and only deletes records generated by them
    • Does not affect production data
  • Sandbox | Production environment tabs — View logs for each environment independently (Learn more about environment tabs)

Search filters

The search area has two tabs: Period Search and Field Search.

Period search filter

Filter logs by time range and status.

  • Date basis — Choose Processed at or Created at. Default is Processed at
  • Start / End date — Specify the time range
  • Status — Choose All / Success / Failed / Webhook failed
    • Webhook failed shows only calls that were stored but whose webhook never reached your server, or is still being retried. Choosing it clears the Record ID and content search conditions
  • Collaboration keyAll or a specific collaboration key (shows only calls made with that key)

Field search filter

Use this when you want to find logs by a specific value.

  • Field selection:
    • Record ID — Exact match by record ID (prefix match supported)
    • Content search — Substring match (case-insensitive) anywhere across the full payload, minimum 3 characters
  • Enter Search value and execute
  • When Content search is selected, Start / End date inputs appear. If dates are not specified, it searches within the last 30 days by default

How content search works (and its limits)

  • Search scope: Substring match against the entire payload (the JSON document) serialized as text
  • Multilingual: Works for Korean, English, Japanese/Chinese characters, etc. (English is case-insensitive)
  • Numbers are searchable but match as substrings: e.g., "32" matches age:32 as well as 132, 321, and any other text containing 32
  • JSON keys are also indexed: searching common key names like "name" or "address" will match every record — use more specific terms
  • Not supported: comparison operators (>, <, =), exact-value match, field-scoped queries

Log list

Log list

Below the search filters, the endpoint's call history is displayed in a table.

Column Description
Record ID Record identifier
Status Success · Failed · Pending badge
Webhook A badge appears only when a delivery failed or is being retried (see below)
Collaboration key Collaboration key used for this call (or default if none)
Created API call reception time
Processed Storage and webhook processing completion time

Reading the Webhook column — This column only appears on endpoints that have a webhook configured.

Badge Meaning
502 Failed — Every retry was used up and the delivery never got through. The number is the status code your server returned; if there was no response at all it reads Timeout
502 (3/6) Retrying — The parentheses show current attempt / total attempts (6 in production, 4 in sandbox — the first delivery counts as attempt 1). The next retry time is on the log detail page
Recovered It failed at first but got through on a later retry

A blank cell does not mean success. Only failed deliveries are recorded, so a webhook that went through leaves no trace at all. On endpoints with no webhook configured the column is hidden entirely.

If a single call has both an owner webhook and a collaborator webhook, the list shows only the more severe of the two. Open the log detail page to see them separately.

Click any row to go to the log detail page.


Log detail page

Overview

Log overview

Shows detailed information for an individual call.

  • Record ID: Unique record identifier
  • Endpoint: The endpoint that received the call
  • Version: Configuration version at the time of the call
  • Processed: Storage and webhook processing completion time
  • Response time: Gateway processing time (ms)
  • Collaboration key: The collaboration key name and description used (if applicable)
  • Error message / Error details: For failed calls, error type, status code, field errors, and occurrence time
  • View Endpoint button — Go to this endpoint's detail page

Webhook delivery

A card that appears only when this call's webhook failed or is still being retried. The owner webhook is shown first, the collaborator webhook below it.

  • Status badge and attempt count — The same badge as the list, alongside N attempts, the status code, the last error, and the receiving host
  • Response — The raw response body your server returned (truncated). It is close to the only thing that separates a firewall (WAF) block from your app rejecting the request. There is a copy button
  • Attempts — Each attempt's time, status code (or Timeout), and duration in ms. Attempts triggered by the automatic retry are marked auto retry
  • Next retry — The scheduled time, if attempts remain

Only failed deliveries are recorded. A webhook that went through leaves no entry here, so the absence of this card means "no failure was recorded", not "delivery was confirmed".

There is no manual resend. All retries are automatic, and once they are exhausted the delivery cannot be sent again. Once you have fixed your receiving server, the next API call will be delivered normally.

You do not have to watch this screen. We email you — on every plan, Free included — when a production owner webhook delivery is given up on — at most one message per endpoint per day. This screen is still where you look up the individual attempts and the response body.

For the retry intervals and which responses are retried, see the Test & Integration Guide.

Payload

Payload section

Shows the original JSON data sent with the API call.

Danger Zone

Danger Zone

  • Delete log record — Permanently removes this log record
  • The record itself and its associated payload are deleted. This cannot be undone
  • Usage statistics are not affected

The right side of the detail page shows a quick link card to jump to the endpoint detail page for the current log. You can quickly check the endpoint's settings, webhooks, collaboration keys, and more.


Troubleshooting

  • Logs are empty: The Production tab shows no records until production deployment. Check that test calls are being recorded on the Sandbox tab first
  • Search returns no results: Either your search term is under 3 characters or no records match within the date range. (1) Try a shorter or more specific term (a 2–3 character Korean word, or part of an English word), and (2) widen the date range to within 30 days. The old "searchable fields" setup step has been removed — no per-field configuration is required.
  • Want to see calls from only a specific collaborator: Select the collaboration key from the Collaboration key dropdown in the Period Search tab
  • The Webhook column is blank — does that mean it was delivered?: No. Only failed deliveries are recorded, so a blank cell means "no failure was recorded". No webhook configured, a delivery not yet attempted, and a successful delivery all look identical
  • Turning on the webhook filter cleared my search term: Webhook failed queries in the opposite direction, so it cannot be combined with Record ID or content search. The date range and collaboration key conditions are kept
  • Can sandbox clear be undone?: No. Cleared sandbox call records and statistics are permanently deleted. Use with caution