> ## Documentation Index
> Fetch the complete documentation index at: https://docs.periphery.exposed/llms.txt
> Use this file to discover all available pages before exploring further.

# Emails and credentials

> How Periphery finds email addresses and credentials on a page, what verified means, and what each plan shows.

## Email addresses

Addresses are extracted from the rendered page: the visible text, `mailto:` links, and inline script data. They are lower-cased and de-duplicated. The `user:password@host` part of a URL, as in a database connection string, is not an address and is left to the credential scan. Every plan sees the full list on an app page and in the API, and the `email:` filter is available to everyone.

An address on a page is not proof of anything beyond its presence there. Contact addresses, marketing footers, and example data all appear.

## Credentials

After the page is rendered, its source is scanned for strings that match the shape of an API key, token, or secret: cloud provider keys, payment and messaging service tokens, database URIs, and hundreds of other formats. Each match is a **finding** with the name of the **detector** that matched it.

A finding is **verified** when the scanner was able to confirm it with its issuer at snapshot time, for example by making an authenticated call that succeeded. Unverified findings are kept too; they may be revoked, malformed, or placeholders, and the format alone is no guarantee.

Verification happened at snapshot time. A verified credential may have been revoked since; an unverified one may never have been valid.

The list of findings never shows a credential in full. On Plus each finding comes masked: up to the first 8 and last 4 characters around a fixed-width mask, such as `sk_live_••••••••0000`. That is enough to match it against the keys in the issuer's dashboard, which list keys the same way. Shorter secrets show fewer characters.

The page source the scan ran over is never shown, in the console or the API. The extracted text and the screenshot show what the page displayed when it was captured, so a secret the page printed on screen appears in them as shown. Treat them as sensitive.

## What each plan sees

| | Free | Plus |
| - | - | - |
| Email addresses | yes | yes |
| Whether an app has a verified credential | yes | yes |
| Names of the detectors that verified | yes | yes |
| Masked credential values | no | yes |
| Extracted text and screenshot, as captured | yes | yes |
| `has:creds` filter | no | yes |

On the Free plan an app page shows the detector names with a lock in place of the masked values. The API, available on Plus, includes the `credentials` array once the page has been scanned for credentials, empty when nothing was found.

## Using what you find

A credential surfaced by Periphery may be used only to notify its owner. Using it to access, change, or disrupt a system you are not authorised to test breaches the [acceptable use policy](https://docs.periphery.exposed/policies/acceptable-use.md) and, in most places, the law.

If you are the owner, treat a verified finding as evidence that the credential worked **at snapshot time**, not as a reason to test it again. Revoke or rotate it first, update the systems that depend on it, and then remove the secret from the public page or build output. Taking the page down does not revoke the key.

For a step-by-step response, see [Respond to findings](https://docs.periphery.exposed/workflows/respond-to-findings.md#an-exposed-credential).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.