Guide to the Request Log API

The Request Log API lets you read back the calls your company has made to the Everee Integration API, so you can find out for yourself why a request failed, what exactly was sent, and whether you're still using anything that's deprecated. Entries are kept for 30 days.

You authenticate the same way as every other endpoint: your API token and tenant ID. See Authentication & API tokens. The endpoints only ever return your own company's calls. For a worked example, see Diagnosing a failed request.

What's recorded

The log covers calls to the Integration API (paths beginning /integration/v1) that were authenticated with your company's API token. It doesn't include:

• Calls to anything outside /integration/v1
• The Request Log API's own endpoints
• Embedded session endpoints
• Calls that couldn't be authenticated, since there's no company to attach them to
• Calls rejected because you exceeded a rate limit (429), which are turned away before they reach the Integration API

Recording is best-effort. It never slows down or fails your requests, and in rare cases, such as a disruption on Everee's side, a call may not be recorded. Calls usually appear within a few seconds.

The log's endpoints are served at /integration/v1/api-calls.

Reading an entry

Every response carries a requestId, which is the X-Request-ID header that came back on the original response. It's the fastest way to find a particular call, and it's what to give Everee Support when you ask for help. See Requests & responses.

The list returns a summary of each call:

Getting a single entry adds the stored detail:

What's stored, and what's masked

Everee masks sensitive values before anything is stored, so the log never contains them. Instead you'll see a placeholder naming where the value was, for example <<REDACTED:/workers/0/ssn>>, and redactedFields lists every location.

• Request headers are an allowlist. Credentials such as Authorization are never stored.
• Request bodies are stored only when they're JSON and 256 KB or smaller. Otherwise requestBodyStored is false, and requestBodySize still tells you how big it was.
• Response bodies are stored only for failures. Calls that returned 400 or above have their error response stored. Successful responses aren't.
• Error messages are masked too. Because an error message can echo what you sent, dashed Social Security numbers and EINs, and any number of 8 or more digits, are replaced.
• Masking errs on the side of caution. If a body can't be reliably inspected, it isn't stored.

Treat the log as a diagnostic aid. A masked value means you can't see what was sent in that field, but you can tell it was present.

Filtering

All filters are optional and can be combined.

Paging

The list is cursor-paged, newest first. It accepts:

• size: the number of entries per page. Defaults to 20, maximum 200.
• after: the nextCursor from a response, to get the next, older page. Leave it out for the first page.
• before: the previousCursor from a response, to get the newer entries before it.
• sort: createdAt,desc (the default) or createdAt,asc for oldest first. It's the only field you can sort by.

Responses contain items, pageSize, hasNextPage, hasPreviousPage, and the cursors. Treat cursors as opaque and pass them back as you received them. New calls arriving while you page don't cause entries to be skipped or repeated. Note that unlike most cursor-paged endpoints, this one uses size rather than limit, and also supports before. See Pagination.

Finding deprecated usage

When something in the API is deprecated, the log tells you which of your calls still use it, so you know what to change before it's removed. Each entry records, by name only and never by value, whether the call used:

To find everything affected:

1. List entries with uses-deprecated=true.
2. Look at deprecatedUsages on an entry (get it by ID to see them). Each has a key, such as BODY_FIELD:/dimensions, along with forRemoval and since when known.
3. Pass a key as deprecated-usage to list every call that used that same thing.

Detection has limits. It can't see calls that were rejected before they were routed to an endpoint, bodies over 256 KB or that aren't valid JSON, or deprecated alternative field names, so an empty result isn't a guarantee you're clear. Use it to find usage, not to prove there's none.

Troubleshooting: "my call isn't listed"

• The call was made to a path outside /integration/v1.
• The call wasn't authenticated, for example because the token was rejected, so it can't be attributed to a company.
• The call was rejected with a 429 for exceeding a rate limit.
• The call was made seconds ago. Entries usually appear within a few seconds.
• The call is older than 30 days.
• Your filters are too narrow. Remember that path matches a prefix and that handler-pattern must match exactly.