How do I use the API process queue?
See queued API events, identify errors, and safely clear the queue if necessary.
API process queue monitoring basics
The API Process Queue is a read-only report for operational monitoring of the API queue. It lets you see what API processes and messages are in the queue, why processing may appear to be stuck, and which rows have an error logged. You can view the most recent queue rows, but you cannot change, retry, or delete rows from the report.
Open API Process Queue Report
The API process queue report is opened from the Reports center.
- Open Reports at
/reports. - In the Search reports field, select API process queue or search for the report in the Operational group.
- From the report card, select Run Report .
- In the panel that opens, select Preview .
The report has no custom parameters, date range, or row filters. The preview displays up to the 100 most recent rows in descending order by tag. If the result is truncated, the panel displays a notification.
Understand the role of the queue
The role of the API process queue is to separate interface work into its own api_process_queue rows in the database. The queue can be used to process large amounts of updates separately from the original request, so that all the work does not have to be done at once within the time limit of a single request.
The report does not tell you the processing speed of the queue, the batch size, or the time of the next run. So, do not promise a specific number of rows per minute, for example. The newest rows are displayed first, but the appearance of a single row alone does not prove whether the job is waiting, currently processing, or has failed.
Interpret the report columns
The technical column headings in the report are:
| Column | Contents |
|---|---|
id |
A unique identifier for a queue line. A larger identifier is usually a newer line. |
jobId |
The queued job identifier, if one is stored. |
api |
Interface or target system identifier. |
endpoint |
The interface path to be processed. |
method |
HTTP method, such as GET , POST , or PUT ( GET/POST are common values). |
createdAt |
The queue line creation time. |
error |
Stored error information. A blank value means that there is no error stored in the row at the time of reporting. |
The report does not show the actual message data stored in the queue. Also, based on the row alone, you should not conclude with certainty whether the message is coming into or going out of AI Commerce . Identify the owning integration using api , endpoint , method , and jobId values.
An inbound message can be generated when an external system reports a change or AI Commerce retrieves changes. An outbound message can be generated as a result of an action taken in AI Commerce . The report does not name the direction in its own column, so verify the direction with the integration documentation or technical owner. Do not make new changes in the external system just to get messages to appear in the report.
Resolve the queue error
An API process queue error is first investigated based on the frequency of the same error and the interface context. When there are many errors in the queue, open the report and check the number of rows, creation times, and whether the errors are related to the same interface. Check at least:
- Does the same
erroroccur in several of the latest lines? - Are
apiandendpointthe same in all error lines? - Do the rows relate to the same
jobIdvalue or to multiple different jobs? - When were the first and latest error lines created?
- Are there also lines in the same interface where
erroris empty?
Save id , jobId , api , endpoint , method , createdAt , and the entire error value for your records. Fix the root cause of the error in the workflow of the interface or its owning integration. Don't assume that deleting the entire queue will fix an incorrect message or connection issue.
If the same error accumulates on many lines, the interface processing may be stuck or new error messages may be generated continuously. However, the report alone does not prove that the entire interface has stopped. First determine whether the problem affects incoming or outgoing work, correct the error in the owning system, and only then agree on a possible retry.
A small delay between message generation and processing may be part of the queue work, but the report does not specify an acceptable delay. Upon successful processing, the integration code may delete individual rows, but the report does not promise automatic resetting of the entire queue after a certain period of time.
Export a larger sample to a CSV file
A larger sample of the API process queue is exported using the Export function in the reports panel. Use export when you need data larger than the preview or want to submit rows for technical analysis. The completed export is downloaded using the Download CSV function. The CSV contains the same seven columns as the preview.
The export contains a maximum of 5,000 latest rows. The report does not have a date, interface, or error filter, so limit the data in the CSV processing tool if necessary. Treat the file as operational log data and share it only with those participating in the investigation.
Do not clear the queue from the report.
The API process queue cannot be cleared from the report, as it does not have a delete function. The report is intended for observation and export.
If error rows require retry, quarantine, or deletion, provide the tags to the integration technical owner and use only the approved rollback procedure for that integration. Clearing the entire queue may also remove unprocessed, error-free jobs and should not be used as a general troubleshooting measure.