Filtering and Searching

The Logs page provides several filters that let you narrow down your API activity to exactly the requests you care about. All filters are applied together — if you set both an API key filter and a status filter, you’ll only see requests that match both.

​

Date Range

The date range picker controls which time window Lettr queries for log data. By default it covers the last 7 days. You can extend it up to 30 days into the past — this is the maximum retention period for API logs. Dates beyond that are no longer available, and the picker doesn’t offer future days. The picker includes both a start and end date, as well as start and end times. Your local time is converted to UTC before the query runs, so you don’t need to think about timezone conversion yourself.

​

API Key

If your account has multiple API keys, this filter lets you isolate requests made with a specific key. This is particularly useful when you have separate keys for different environments (staging vs. production) or different services. Select All API Keys to see everything, or choose a specific key from the dropdown.

​

User Agent

Lettr automatically detects the client type based on the user agent string in each request and groups them into recognizable categories. The available options are: Selecting Other is useful when you’re trying to identify unexpected traffic sources on your account.

​

HTTP Status Code

Filter by the response status code to focus on successes or errors: Filtering by 4xx or 5xx status codes is the fastest way to find failed requests when debugging an integration.

​

Pagination

Log results are paginated using cursor-based navigation. The footer of the table shows how many requests are displayed on the current page, along with Previous and Next buttons. Cursor-based pagination means the results are always consistent — new log entries appearing in real time won’t cause items to shift between pages as you navigate. When you apply or change any filter, pagination resets to the first page automatically.

​

Inspecting a Log Entry

Click the info icon on any row to open the detail dialog. This shows:

• The Request Body — the JSON payload your application sent, with large and sensitive fields shortened. This is where you can verify that fields like from, to, subject, template_slug, and options are structured correctly. html, text, and amp_html are cut off after 200 characters, and substitution_data, metadata, and attachments are replaced by a count such as "3 items" — see Truncated Fields.
• The full Response Body — exactly what Lettr returned. For successful requests this includes the request_id and other confirmation data. For errors, it includes the error code and message.
• The IP Address and User Agent string, along with the API Key name and prefix.

​

What You Can’t Filter By

Logs record API requests, not emails, so the filters are about the request: when it was made, with which key, by which client, and how it ended. There is no filter for template, recipient, subject, or email content.

​

Merge Tag Values Are Not Stored

The request body shows substitution_data as a count ("3 items"), never the values themselves, and no other page shows them either. Merge tag values routinely contain personal data such as names, addresses, and order details, so Lettr uses them to build the email and then discards them rather than keeping them in logs. The count is still useful: if it shows fewer items than the template has merge tags, your application didn’t send all of them. To check the actual values, log the payload in your own application at send time, or send the same request with a sandbox API key — the email is delivered to your own address, so you can inspect exactly how the values were rendered.