Experience API Logs

The API logs provide an in-depth overview of your Experience API calls, including events, pageviews, clicks, and choose variation calls. They enable you to verify that your API calls are correct and identify implementation issues. You can also use logs to troubleshoot unexpected behavior.

Note that logs are near real-time, but not necessarily up to the exact moment.

To access the API Logs in Experience OS, go to Settings › API Logs.

API Logs details

The timeline aggregates API calls into successful calls, calls with errors and calls with warnings. Hover over a bar for more details.

Under the timeline, a table lists the recent API calls that occurred in the selected time range. Press Load More to see more API calls.

The following fields are available. To display more fields, click Columns at the top of the API Logs page.

Column	Detail
Endpoint	The type of API calls, such as choose or pageviewDetailDetails about the request type, such as what type of event was called
Request ID	A unique identifier for each API call
Status	Displays the status code. 200 or 204 means everything was ok. Other codes are described next to the code.
User ID	The user ID provided in the API request
Session ID	The session ID provided in the API request
Timestamp	Displayed in seconds granularity
Request Duration	The time the request took in the Dynamic Yield servers (excludes time spent in transit)

You can drill down on any API call to view more details by clicking anywhere in the row. This response is only available for logs that are under 32 KB. If the response exceeds this limit, it won't appear in the log at all (it doesn't mean that there was an error in the response itself or that it was not delivered properly).

Select a time range

Specify the time range by using the date picker:

You can also zoom in on a specific time range by clicking and dragging a box over the range you want.

A banner indicating the time range you set appears. Click X to undo the zoom

Filter the log

In the filter pane, you can filter the API calls by date, duration, type, status, or errors. The number of calls per filter appears next to each filter option.

Multiple selections under the same filter type (say, Choose and Pageview under Endpoint) are considered as "OR"; while multiple selections under different filter types (say, Pageview under Endpoint and Error under Status) are considered as "AND".

You can also filter by using the search tool to specify a userID or a requestID.

Troubleshooting use cases

Issue	Resolution
During the initial implementation, I want to make API calls to check that all attributes are received with the intended values (context type, for example) and no warnings.	Open the API Log and monitor the incoming calls, using the refresh button to view the latest calls.
During implementation, I noticed there were some warnings on API calls.	Select the row in the API log to see more details. You can see the full warnings, including, for example, specific missing SKUs. You can also view the request body to see exactly how you passed the data to the API.
In production (or any other high-volume environment), I suspect there might be some problematic API calls, but I am not sure exactly when they're happening.	You can zoom in on a specific time range that has a high volume of errors or warnings. You can also use filters to view only API calls with the errors or warnings you're looking for.
On a high-volume platform, I want to see what one user is doing.	Enter their user ID in the search bar to filter the log.
Someone wants to tell me about an issue by sharing a bookmark or reference to the issue.	This can be accomplished by entering the User ID in the search bar. If you don’t have the user ID, enter the request ID and use that to look for the user ID in the filtered results.
I know there are currently errors/warnings, and I want to know “when it broke”, so I can (a) understand the scope of the problem, and (b) correlate it with any changes I made.	Zoom in to a suspected time range, and then use filters to narrow down the results to a specific error or warning type.
I applied a fix to an error/warning and want to check that there are no more requests with this type of issue.	Use the time-range control and/or filters to see if/when a problem stopped and whether the issue was fully or partially resolved.