Can Requizon store API keys or passwords?

Request parameters are redacted by name, so a parameter called api_key or password is stored as ***. Two things can still hold credentials: an XML or plain-text body if you enable store_unparsed_bodies, and the response body of a failed call, which is stored unredacted. Keep detail_days short and treat http_requests as sensitive.

Redaction and stored data

Which request parameters are masked, which bodies are stored by shape only, and the one thing stored as-is.

A recorder for outbound calls sits exactly where your credentials travel: API keys in query strings, passwords in login bodies, tokens in headers. Where Requizon cannot tell whether something is a secret, it leaves it out. This page lists exactly what it keeps, including the one place it stores data as it found it.

What a row holds#

Column	Stored
`api_name`, `host`	As described in Naming APIs
`method`, `status_code`, `duration_ms`	As they were
`path`	Normalised, without the query string. See Paths
`failure_type`, `failure_message`	For failures only. See Failure detection
`request_params`	Redacted, as below
`response_body`	For failures only, unredacted

Request and response headers are never stored, so an Authorization or X-Api-Key header does not reach the table in any form.

Request parameters#

Where the parameters come from depends on the method:

GET and DELETE: the query string, parsed into named parameters. A body is ignored.
Every other method: the body. A JSON body (a Content-Type containing json) and a form body (application/x-www-form-urlencoded) are parsed into named parameters. Anything else is unparsed. The query string is not recorded.

Redaction#

Before storage, every parameter's name is lowercased and checked against two lists. A match replaces the value with ***. Nested arrays are walked, so credentials.api_secret is caught as well.

'recording' => [
    // ...

    // Redacted when the name contains one of these: user_password, api_secret_key, auth_token
    'redact_patterns' => ['pass', 'secret', 'token', 'apikey', 'api_key', 'auth'],

    // Redacted on an exact name match, for APIs that abbreviate: ?l=user&p=password
    'redact_exact' => ['p', 'l', 'pwd'],
],

{
    "username": "rest@example",
    "password": "***",
    "periodFrom": "12.10.2026",
    "credentials": { "api_secret": "***", "region": "eu" }
}

Add the names your own APIs use. When you replace either list in your config, include the defaults you still want: the list you write replaces the default one.

Substrings over-redact

Matching on part of a name is deliberately generous. pass also catches passenger_count and auth catches author, and those values are stored as ***. If a parameter you need to read is being hidden, rename the pattern to something more specific (password instead of pass) rather than removing it.

Bodies Requizon cannot parse#

Redaction works by parameter name, so a body that cannot be parsed into names is a body whose credentials Requizon cannot find: XML, SOAP, text/plain, multipart/form-data uploads, and anything with no usable Content-Type. By default such a body is recorded by shape only:

{ "_unparsed": "application/xml, 1482 bytes" }

If you know your unparsed bodies carry nothing sensitive, store them. They are kept verbatim, cut to recording.request_body_max_bytes (4 KB):

'recording' => [
    // ...
    'store_unparsed_bodies' => true,   // stored as {"_raw": "<?xml ..."}
],

Two kinds of body are never read at all. A body larger than recording.max_body_read_bytes (256 KB) is recorded by shape from its declared size, which keeps a file upload from being loaded into memory on every request. A body that cannot be rewound after reading is skipped, and the row has no parameters.

Response bodies are stored as they arrived#

The response body of a failed call is stored so you can read what the API actually said, and it is not redacted. Parameter names in an arbitrary response are not a reliable signal, and a body with values masked is much less useful when you are debugging it. What that means in practice:

An API that echoes your request back in its error response stores your credentials in http_requests.
A 401 or 400 from a token endpoint can contain the token request it rejected.
A failed call to an API that returns personal data stores that personal data.
A message returned by your failure detector is stored as-is too.

These are the settings that bound it:

retention.detail_days decides how long those bodies exist. The default is 14 days; a few days is often enough to debug with. The hourly rollup holds no bodies and is unaffected.
recording.response_body_max_bytes caps how much of each body is kept (64 KB).
connection can put Requizon's tables on a separate database with its own access controls and backup policy.
ignore_hosts keeps an API whose traffic must not be stored anywhere out of the table entirely.

Treat http_requests as sensitive

Give it the same care as your application logs: restrict who can query it, think about what your backups copy, and keep the viewRequizon gate as narrow as the table deserves. The dashboard shows these bodies to anyone the gate lets in.

Secrets in URLs#

The query string is never part of the stored path, and a path segment longer than 40 characters is stored as :id, which covers most signed tokens. A short secret placed directly in the path, such as /hooks/abc123/send, is stored as written. Use a path resolver to mask it for that host.