Privacy

Summary

Requests you send through the tester

When you press Send, your browser posts the request details — target URL, method, headers and body — to this site's proxy endpoint. The server opens a connection to the target, forwards the request, reads the response and hands it back to your browser. The URL, headers and body exist only in server memory for the duration of that exchange. They are not written to a database, not written to a file, and not printed to a log.

A server-side proxy is needed because browsers enforce the same-origin policy: a page on one domain cannot read a response from an API on another domain unless that API opts in with CORS headers, and most do not. Forwarding through a server — which is not a browser and not subject to CORS — is what makes testing arbitrary public endpoints possible. The HTTP headers guide explains CORS in more detail if you want the mechanics.

The practical consequence you should understand: the request passes through our server in the clear before being re-encrypted to the target over HTTPS. We do not record it, but the design means it is technically visible to the server at the moment of forwarding. If you are testing against production systems with real customer data or long-lived secrets, use a local client instead. That is not a warning specific to this site — it applies to every browser-based API tester that proxies requests.

Credentials

Anything you enter in the Auth tab — a bearer token, Basic auth username and password, or an API key header value — is used for one purpose: constructing the header that signs that single request. It is sent to the target API as part of the request and then discarded along with everything else.

• Credentials are not written to localStorage, so they are gone when you reload the page.
• Credentials are not stored server-side in any form.
• Credentials are not included in your request history, which records only the method and URL.

The JWT decoder, Base64 encoder and the other browser tools do all of their work locally in JavaScript. Tokens and strings you paste into them are never sent to the server at all.

Request history

The History tab is stored entirely in your browser using localStorage, under the key apitester.history. It holds the method and URL of your most recent requests — currently the last twelve — and nothing else. No headers, no bodies, no credentials.

This data never leaves your device. It is not synced, not backed up and not readable by us. To clear it, clear site data for api-tester.com in your browser settings, or delete the apitester.history key in your browser's developer tools. Using a private or incognito window means it is discarded when you close the window; if localStorage is unavailable, history is simply skipped and the tester works normally.

Webhook URLs

The webhook tester and the webhook example pages work differently from everything above, and it would be misleading to let the "nothing is stored" statements cover them. When you create a webhook URL, this server does keep what is sent to that URL — that is the feature. For each request it holds the method, path and query string, every header, the body, the time it arrived and the IP address it came from.

• It is held in process memory only. Nothing is written to a database or a file, and a service restart erases every inbox.
• An inbox keeps its 50 most recent requests, accepts bodies up to 256 KB, and is deleted 24 hours after it was created. You can delete it sooner with the Delete URL button, or empty it with Clear requests.
• The URL is the only access control. There are no accounts, so anyone who obtains the URL can read everything it has received, and can send requests to it. Treat it as a secret, use it with sandbox and test-mode accounts, and do not send production traffic, customer data or live credentials through it.
• Some providers will not use a webhook URL until it returns a challenge value they send. The inbox answers those verification requests from Slack, Twitch, Meta (WhatsApp), Dropbox, Okta and Asana by sending back the value it was given, and records the request like any other.
• Zoom is different, and involves a secret. Zoom's verification can only be answered with a hash made from your Zoom app's Secret Token, so the Zoom example page lets you save that token against an inbox. If you do, the token is sent to this server and held in process memory for as long as the inbox exists. It is used only to answer validation requests that carry a valid Zoom signature made with the same token, it is never displayed or returned to anyone, including you, and it is erased with the inbox. It is still a credential stored on someone else's server: use the token of a development app, and regenerate it in Zoom afterwards.
• Your browser remembers the URL in localStorage under apitester.hook so the inbox is still there after a reload. That entry never leaves your device.
• Open in API Tester passes one captured request to the request console through your browser's sessionStorage (apitester.prefill). It is read once, deleted immediately, and never sent to us until you press Send.

We do not read inbox contents, and they are not used for anything except showing them back to whoever holds the URL. The path of a webhook URL does appear in the web server's access logs, as described below.

IP addresses and rate limiting

The proxy is rate limited to 60 requests per minute per IP address to keep the service responsive and to make it unattractive as a relay for abuse. Implementing that requires knowing which requests came from the same place, so the server keeps an in-memory map of IP address to recent request timestamps.

That map is transient. Entries older than the 60-second window are swept away automatically, and the entire structure lives in process memory — it is never written to disk and it is lost completely whenever the service restarts. It is used for nothing except counting requests in the current window. If you exceed the limit you get 429 Too Many Requests with a Retry-After header, and normal service resumes a minute later.

Web server logs

To be accurate rather than absolutist: the web server in front of the application writes standard access logs, as essentially every web server does. Each line records the client IP address, timestamp, the request line (for example POST /api/proxy or GET /learn/http-methods/), the response status and size, and the referring URL and user-agent string the browser sent.

These logs are used for operational purposes only — diagnosing errors, spotting abuse, keeping the service running. Importantly, for proxied requests the log line shows only that /api/proxy was called. The target URL, your headers, your body and your credentials travel in the request body and do not appear in these logs. Requests to a webhook URL are logged the same way: the line records the sender's IP address and the request line — the webhook URL's path and any query string the sender put on it — but never the headers or the body. Logs are rotated daily and deleted after 14 days. They are not shared with anyone and not used for analytics or profiling.

Cookies, analytics and third parties

This site sets no cookies. It runs no analytics — no Google Analytics, no Plausible, no Fathom, nothing. It loads no third-party scripts, fonts, tag managers, advertising pixels or embedded widgets. Every stylesheet, script and asset is served from api-tester.com itself. There is no cookie banner because there is nothing to consent to.

There is no signup and no account system, so there is no name, email address, password or profile associated with you anywhere in this system.

Third-party APIs you choose to test

One thing genuinely outside our control: when you test an endpoint, the request reaches whoever operates that endpoint, and their privacy practices apply to it. They will typically log the request, including any credentials you sent, and they will see our server's IP address rather than yours. If you are testing a third-party service, its privacy policy governs what it does with what you send.

Requests to loopback addresses, private network ranges and cloud metadata endpoints are blocked, and every hop of a redirect chain is re-validated, to prevent the proxy being used to reach systems that are not publicly reachable. The about page covers those limits.

Data retention at a glance

Changes to this page

If how the site handles data changes, this page changes with it. It describes current behaviour, not aspiration — if you spot a discrepancy between what is written here and what the site does, that is a bug worth reporting.

More about how the service is built is on the about page. If you came here from the tool, head back to the API tester, or read the guides on REST API testing and HTTP methods.