https://api.echonova.aiDevelopers
Read the request log
Open the Request Log tab, read what each column means, find the call your system made, and know which requests are never recorded.
Every request on the Developer API whose key EchoNova found is recorded, and the portal lists the most recent ones under Developers on the Request Log tab. Use it to confirm that a call reached EchoNova, to see the status it was answered with, and to tell which key made it. For totals, charts and filters, use Activity.
What you need
- An EchoNova account and a workspace with at least one API key. See Get an API key.
- The workspace owner's access, which includes the
developer_api.viewpermission. - At least one request made with a key. Until then the tab shows No requests yet.
Steps
Step 1: Open the Request Log tab
Go to /developers?tab=request-log, or open Developers in the portal and
select the Request Log tab. The tab loads the 50 most recent requests,
newest first.
Step 2: Read the columns
Each row is one request. The tab shows no column headers; a row shows these fields from left to right:
| Field | What it shows |
|---|---|
| Code | The HTTP status your client received, for example 200, 400 or 503. A successful call shows 200. |
| Method | POST, GET or DELETE. |
| Request | The path, for example /v1/text-to-speech/sync. The query string is not recorded. |
| User | The Name of the API key that made the request. |
| Timestamp | When the request was recorded, in your browser's time zone, for example Sep 15, 2026, 10:21:04 AM. |
Step 3: Find the call you are looking for
Rows are sorted newest first, with no filter. Use your browser's find
function on the page. Every call is recorded, so each poll of a job with GET
has its own row. The POST that created a job has a row too, recorded as
200 when it succeeded.
Every API response carries an X-Request-Id header. Log it on your side and
look the same value up as Request id on the Logs tab of
Activity, where each row also shows the service,
the voice, the billed credits and units, and, for a failure, the error
message.
To find one call, paste its X-Request-Id into Find by request ID on the
Logs tab. It shows that call from the last 365 days, whatever the period
and filters. Clear the box to go back to the list.
Match the log to your own records by the request id. The log shows the path, the status and the key; everything else about a call lives in your logs.
Recommended
- Your server logs each request with the key name and the
X-Request-Idit got back, and you look up that request id on the Logs tab of Activity.
Less effective
- Your server logs nothing and you scan the 50 most recent rows by timestamp after an incident.
What happens next
- The tab loads once when you open it. Reload the page to see requests made since.
- A request is recorded after the API has answered it, whatever the
status: a
200and a400both get a row, and so does a403. Only the first per-key429of each limit window gets a row; later ones in the same window do not. The row keeps the status your client received. An accepted asynchronous job keeps200even if it fails later. GETandDELETEcalls, such as polling a job or listing voices, are recorded too. They charge no credits.- The log holds API rows only. Portal runs and agent usage get no rows; their credits show in Credits history.
- Deleting a key does not delete its rows, and the user field keeps showing the key's name.
- Rows are deleted 365 days after the request.
Limits
| Limit | Value | Applies to |
|---|---|---|
| Rows shown | 50, newest first | The Request Log tab |
| Filters, paging, export | None; use Activity for those | The Request Log tab |
| Recorded per request | Method, path, status code, response time, key, timestamp, request id, service, voice, billed units, error message | Every row |
| Not recorded | Request body, headers, query string, response body, client IP address | Every row |
| Requests recorded | Requests of any method whose API key was found | The /v1 endpoints |
| Retention | 365 days after the request | All rows |
Troubleshooting
No requests yet
No request made with a key from this workspace has passed authentication.
Make one request, for example POST /v1/text-to-speech/sync with a valid key,
then reload the tab.
A request my client made is not listed
A request can be missing when it was rejected before EchoNova knew the key.
Any 401 (missing or malformed header, unknown, disabled or deleted key,
closed workspace) and the per-IP 429 are answered before that, so neither
gets a row. A body over 100 KB (413) or a body that is not valid JSON (400)
is also rejected before the key is checked, so it has no row either. The same
goes for an unknown route (404 Route not found) and a wrong method on an
existing path (405 Method not allowed), because no key is checked. A 403
and the per-key 429 come after the key is found. A 403 is always recorded,
and only the first per-key 429 of each limit window is recorded.
A row shows 200 for a failed job, or 201 for a POST
The API accepted the job and answered 200, so the row keeps 200. When the
job fails later, its credits are refunded and the row does not change.
Older rows can still show 201 for a successful POST until they expire
after 365 days. Every other row shows 200 for a success.
User shows Unknown
The key could not be found. A key you deleted from the portal still shows
its name; Unknown appears only when the key no longer exists at all.
FAQ
Does the log show requests made with a wrong or disabled key?
No. A 401 is rejected before EchoNova knows the key, so it is not recorded. Watch the key's
Last Used date instead: it moves on every request that passes
authentication, including ones later rejected by the rate limit.
Can I filter by key, status or date?
Not on this tab. Every row of the 50 most recent requests is shown; use your browser's find function on the page. The Logs tab of Activity filters by key, service and voice, and Export CSV there downloads daily totals.
Can I export the log or read it through the API?
The log is read in the portal only. Log every request on your side if you need a full history or a machine-readable copy.
Does a job get one row or many?
Many, one for each call. The POST that creates a job gets a row, whether it
is synchronous or asynchronous. Each GET you make to poll it gets its own row
too.
Who can see the log?
The workspace owner, whose role has the developer_api.view permission. Managing keys and
webhooks needs developer_api.manage; viewing the log does not.