Open the Usage table
Go to Admin → Custom Features → API → Usage. The API page header keeps the trailing-hour summary visible on every API tab, while the Usage table provides the request-by-request history.
The number before the slash is the total number of identified API requests recorded during the trailing hour. The number after the slash is the displayed hourly limit. The API enforces its fixed one-hour limit independently for each token, so use the X-RateLimit-Remaining and X-RateLimit-Reset response headers when an integration needs the exact remaining allowance and reset time for a particular token.
Filter the request history
The table defaults to Last 24 hours. Open the filters to choose:
- Last hour for the most recent activity.
- Last 24 hours for a normal daily review.
- Last 7 days when investigating an intermittent issue.
- API token to isolate requests made with one token. Clear the selection to show all tokens again.
Select the refresh button to retrieve the latest activity. If the filtered result is longer than the current page, use the standard load-more controls below the table.
Read each request
Each row contains:
- Token — the label of the token used for the request.
- Method — the HTTP operation, such as GET, POST, PATCH, or DELETE.
- Endpoint — the API path that was called. Query strings are deliberately not stored.
- Response — the HTTP result. A 2xx response completed successfully; a 4xx response indicates a request, authentication, permission, or rate-limit issue; and a 5xx response indicates a server-side failure.
- When — when the request was recorded.
No response means the request began but did not reach normal completion, for example because of a fatal error, timeout, or terminated worker.
Investigate unexpected usage
Start with Last hour, then select the token whose activity you are checking. Compare the request times, methods, and endpoint paths with the integration's own logs or scheduled jobs. Repeated calls to the same endpoint can reveal an overly frequent polling loop, while clusters of 4xx or 5xx responses can identify a failing request that is being retried.
Requests rejected before a token can be identified are not shown. This includes requests with a missing or malformed token and requests using a token that has already been deleted, because there is no active token to attribute them to. If expected activity is absent, check the integration's response and authentication logs as well as this table.
