Account security

PostShip has no password. You get in with a code sent by email, or with your Google or GitHub account; you strengthen it with an authenticator app. Everything is set on Account → Security. This page explains each block and what it really protects.

Signing in

On the login page, use a passkey (fingerprint, face, hardware key) with one gesture, or enter your address: “A code is sent to you by email. No password to remember.” Or choose Google or GitHub. There is nothing to define or to forget — a password that opens no door has no place on a screen about security.

Consequence: your mailbox is your account. Whoever reads it can get in. That's the reason for the two-factor authentication below.

Passkeys

A passkey (WebAuthn) replaces the email code: on the login page, “Continue with a passkey” opens the system prompt — Touch ID, Face ID, Windows Hello, or a hardware key — and the session opens. Nothing to type, nothing to receive.

• Add: Account → Security → Passkeys → “Add this device”. The suggested name is the device's (“Mac”, “iPhone”…), editable. 5 keys at most.
• What is stored: the key's identifier and its public key. The private key never leaves your device (or your iCloud, Google or 1Password keychain, which syncs it across your devices — “synced” in the list).
• Bound to the domain: a key created on postship.fr only works on postship.fr. A site imitating ours cannot make it sign.
• Remove: “Remove” in the list. A removed key can no longer open a session; it stays in your keychain, inert, until you delete it there.
• With two-factor authentication: when it is on, the 6-digit code is asked after the passkey, as after an email code.

Two-factor authentication

Account → Security, Two-factor authentication block: “A 6-digit code is requested at every sign-in, from an authenticator app — Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden or any other TOTP-compatible app.”

1. Click Enable, give the device a name (“My phone” by default) and scan the QR code in your app.
2. Enter the code shown by the app and click Confirm. The list shows the device and its date added.
3. Click Add a device to register a second one (“Second device” by default).

Remove a device asks for confirmation: “will no longer be able to validate a sign-in. Your other devices keep working.” Removing the last one disables two-factor authentication (“Disable two-factor authentication?”).

What the session protects

Once enabled, every sign-in — email code or Google/GitHub — goes through the Two-step verification screen before reaching the application. A session that didn't provide the code is only worth a first factor: it's sent back to that screen on every page of the application, and the routes that return your data (the account export, for instance) answer 403 Two-factor authentication required. PostShip checks the session's level server-side, never from the cookie alone: a cookie edited to claim it provided the code doesn't get in.

API keys aren't concerned: a key is a proof in itself, take the same care of it as of your phone.

Linked accounts

Connected accounts block: “Each linked account is a way to sign in. You can't remove the last one.” Link adds Google or GitHub to your account (“Sign in with your Google account.”); Unlink removes it. The button is greyed out when only one way to sign in remains, and the action answers “It's your only way to sign in — link another account before removing it.”

Linking a Google or GitHub account gives PostShip no access to your data there: it's an identity, not an authorisation. Installing the GitHub app for Check Runs is a separate thing (Connect GitHub).

Connected devices

Connected devices card, at the top of Account → Security: every browser and phone where your account is open, with its browser, system, IP address and last activity. This device marks the one you're using.

• Rename gives the device a name (“Thibault's iPhone”); clearing it restores the default name.
• Sign out closes that device's session: it will have to sign in again with a code, a passkey or Google/GitHub. The device you're using leaves through Sign out in the account menu.
• Sign out all other devices closes every session except this one.

A session opened before 25 September 2026 shows as “Unidentified device”: you sign it out like the others.

Changing your email address

Email block, New email address field, Change button. “A confirmation email is sent to the new address — the change only takes effect after clicking the link.” Until then, the old address remains the one that receives sign-in codes and alerts.

What triggers an alert

A sign-in from a device never seen before — a browser, system or device type your account hadn't used yet — sends the “New sign-in to your account” email, with the device, IP address and a button to your devices. The other security emails come from the sign-in itself: the code you receive when you sign in by email, and the address change confirmation.

Limits and plans

Account security is identical on all plans: email code, Google, GitHub, two-factor authentication, linked accounts. What changes with the plan is elsewhere (plans).

Troubleshooting

Why do I get “Two-factor authentication required” on the export when I'm signed in?

Your session was opened before enabling, or was refreshed without going through the code again. Sign out and sign back in: the Two-step verification screen shows, then the export answers.

I lost my phone and I have no second device

If your session is still open in a browser, go to Account → Security and remove the lost device, then register another one. Otherwise, write to support from the account's email address: there is no backup code to find.

Why doesn't the sign-in code arrive?

Check the spam and that the address is the account's. The Resend button sends a new one. If you linked Google or GitHub, sign in that way in the meantime.

Data & retention

How long PostShip keeps each piece of data, how to export it, what the RUM beacon keeps of your visitors, and how to delete an account.

PostShip keeps little, and not for long: the retention window is the plan's, the purge runs every night, and what concerns your visitors is reduced to what a chart needs to know. This page says, data by data, what is kept, for how long, and how to get it back or erase it.

What follows the plan's retention

Every night at 4 am (UTC), a purge erases, project by project, what is older than the owner's window:

• The checks: every run on every URL (check_runs). It's what the Journal, uptime and the latency charts show.
• Real vitals and visitor errors (RUM, errors): a visitor measurement doesn't have to outlive the window we show.
• The log of alerts sent: one line per channel and per send.
• The archived deploy images — social cards, captures and difference images (archive, visual regression). On Discover, only the last deploy keeps its images, whatever its age.

What doesn't follow this window:

Changing plan changes the window from the following night: going from Pro Plus to Pro erases what is older than 30 days.

Export

Each export is a file, without going through a ticket:

CSVs are UTF-8 with a byte order mark, so Excel reads “résolu” and not “résolu”; cells containing a comma, a quote or a line break are wrapped. The account export requires a full session: with two-factor authentication enabled, a session without the code receives 403 Two-factor authentication required. The API and the exports give the same access programmatically.

What RUM keeps of your visitors

The real vitals snippet sends one beacon per page, from the visitor's browser. PostShip keeps of it:

• the page's path, without the query or the fragment — that's where tokens, session ids and pre-filled email addresses live, and what isn't stored can't leak; 200 characters at most;
• the device: mobile or desktop;
• the 4 metrics (LCP, CLS, INP, TTFB), bounded — an absurd value is ignored without rejecting the others;
• for visitor errors: the kind, the message (300 characters, normalised), the source, the line and the column. 10 errors at most per beacon.

No IP address in the database, no user agent, no visitor id, no cookie set. The IP address is only used to rate-limit at reception, and isn't kept with the measurement. The beacon's origin is verified so that a token copied to another site doesn't pollute your measurements.

Delete an account

Account → Danger zone, from reversible to irreversible:

• Revoke every key: API keys and passkeys stop working right now.
• Export your data as JSON, before deleting.

Deleting every project of a workspace is done in that workspace's settings, Deletion section (owner only): the projects, their URLs, history and incidents; the workspace and the account remain. Confirmed by typing the workspace address.

• Delete the account, by typing your email address: “Permanently deletes your account, all your projects, your monitored URLs and the check history. Also cancels the active Stripe subscription if there is one.”

In order: the Stripe subscription is cancelled immediately; your session is closed; the account is deleted, and everything depending on it goes in cascade — projects, URLs, checks, deploys, incidents, status pages, tokens, invitations. What Stripe keeps (invoices, customer) stays at Stripe; it's also what finds your customer record again if you come back with the same address (billing).

A collaborator who deletes their account disappears from the projects they were invited to; the projects themselves stay with their owner.

Troubleshooting

Why does my Journal stop at 30 days?

It's the Pro plan's window. The Journal can't show what was purged. Export it regularly if you need more, or switch to Pro Plus for 90 days.

Why does an old deploy's diff say “changed” without showing the image?

Its images were purged at the end of the window. The comparison of the fields (title, H1, og:image as a URL) is kept with the deploy.

Why did the account deletion fail?

The session is closed before the deletion; if the deletion then fails, the message shows on the login page. Sign in again and try again, or write to support: the account wasn't touched.