What shipped, and when.

Add a sending domain and MailCrow generates a DKIM keypair for it, then hands you the exact records to publish — an SPF TXT record, the DKIM TXT record, and a tracking CNAME. One action re-checks DNS and flips the domain to verified.

Messages, recipients and per-recipient status are stored, not fired and forgotten. Delivery events cover accepted, delivered, failed, opened, clicked, unsubscribed, complained and bounced, and are filterable by type.

Bounces, complaints and unsubscribes land on a per-workspace suppression list, and a send skips any address that is on it. No manual list hygiene, no repeat sends to a dead address.

A template studio for reusable HTML, campaigns for one-to-many sends, and audiences with contacts to send them to — so marketing email lives in the same place as the transactional pipeline.

A daily series of delivered, failed, opened and clicked counters, zero-filled across the whole window so a quiet day reads as a quiet day rather than a gap in the chart.

Machine credentials scoped to a workspace, argon2-hashed at rest with a short lookup prefix. The full key is shown once, at creation, and never again.

Register endpoints with their own signing secret and event selection, so your own systems can react to delivery outcomes.

POST /v3/<domain>/messages is preserved bit-for-bit — multipart parsing, recipient variables and %recipient.x% merge tags included — so anything already written against Mailgun keeps working unchanged.

Ghost speaks Mailgun, not MailCrow, so MailCrow issues it a Mailgun-shaped credential instead: an API key pinned to one sending domain and region, created from the MailCrow dashboard and handed back as a paste-ready base URL, API key and domain block for Ghost’s Mailgun settings.

The MailCrow dashboard is a first-party Paswad OAuth client — public, Authorization Code with PKCE. Connect it once and your workspace is provisioned on the first call; the send API keeps using its own API keys.

OAuth clients carry a verified-publisher flag. Verified applications show a checkmark when they ask for access, and again in the user’s list of connected apps.

Paswad’s own products are verified. A third-party application has to be reviewed before it earns the badge — it is not something an app can set for itself.

The public client-info endpoint returns the verified flag alongside the app name, so a consent screen can render the badge without a privileged call.

The full shape of a mailbox rather than a flat message list — threads, folders, and labels that can be applied and removed per message.

Read and unread, star, flag, archive, move, label, reply, reply-all and forward, plus drafts you can pick back up.

Postgres full-text search over a weighted index — subject and sender rank above the snippet, which ranks above the body — so the obvious match comes first.

Rules that act on incoming mail, a per-account signature, a contact list, and the preferences that make a mailbox feel like yours.

Paswad Mail appears in the Console product catalogue as coming soon until access opens. The Console shows a real coming-soon state for it rather than placeholder data.

A product catalogue with per-app entitlements. An app enables the products it uses, and each product lights up in the Console as its backend lands.

Keys, entitlements, usage, logs, webhooks and custom domains are all scoped to test or live. Switching environment switches everything at once.

A publishable and secret key pair per environment. The secret is revealed once and only its hash is kept, and rotating a key requires a fresh step-up passkey ceremony.

Bring your own domain, verify ownership by DNS, lock the WebAuthn relying-party ID to it, and register your origins. Certificates are issued at the edge, so the Console never holds a private key it does not need.

Create endpoints per environment, rotate the signing secret, fire a test event, and read the delivery log. Deliveries carry a Paswad-Signature header for you to verify.

Invite people as owner, admin, developer or viewer, and change or remove a role later.

Per-app usage with a timeseries, current plan and quota state, usage packs, invoices and payment methods.

An in-console feed with an unread count and per-environment preferences, alongside a console-wide audit log and per-app logs.

A valid Paswad session is no longer enough to enter the Console. Every membership must carry a verified work email first — owners included, with nothing backfilled.

Webhook endpoints and notification preferences were shared across test and live. They are now scoped per environment, so a test endpoint can no longer receive live traffic.

Accounts are pushed to enrol a second passkey. Until one exists, sign-in surfaces a secure-your-account step rather than quietly leaving a single point of failure in place.

Generated on request, shown once, stored hashed. You can check how many remain and regenerate the set at any time.

A recovery attempt needs a recovery code and an email one-time code and a WhatsApp one-time code. Two independent channels, both required — compromising one inbox is not enough.

A completed recovery puts the account into a money-movement freeze for 72 hours, so a successful attack still cannot cash out.

Every registered channel is told the moment a recovery starts, and the real owner can cancel it outright with a single-use link. No liveness check, no video call, no selfie.

The services, the command-line tool, the documentation and the product surface all moved from SchichtID to Paswad.

paswad.com for the site, id.paswad.com for sign-in and the WebAuthn relying party, api.paswad.com for the API, console.paswad.com for the Developer Console.

Every transactional and security message is rendered from a single Paswad HTML system with the brand marks embedded inline, and always ships a plain-text alternative.

The public site you are reading — a static build with sitemap.xml, robots.txt, llms.txt, humans.txt and security.txt, and no third-party framework in the critical path.

The first web passport is a document-verified credential, presented as Verified with the method stated plainly underneath. Face-match and liveness are a separate, later level, not quietly folded into this one.

Read the chip in an ICAO 9303 travel document and verify its signed data object against the country signing authority before a single field is trusted.

Start a verification against a national eID scheme and complete it on the callback, for people whose country already issues a digital identity.

Every attribute shown to a relying party is recorded against that relying party, so a person can see exactly who saw what.

A relying party can verify a presented passport and check whether it is still valid, rather than trusting a screenshot.

First-party Paswad tokens are bound to a device-held key using DPoP proofs. The access token carries the key thumbprint, and a refresh presented on a different key is refused.

Every refresh mints a new token and revokes the one it replaced, with the lineage recorded so a reused token stands out.

A sensitive action can demand a fresh passkey ceremony. For a payment, the challenge is bound to a hash of the amount, currency and payee, and the short-lived token that comes back carries that hash — so an approval cannot be replayed against different details.

Per-identifier and per-IP limits on the sensitive flows, one-time nonces for signed requests, and a registry of device-bound signing keys.

Private signing keys are stored encrypted rather than in the clear, and can be rotated and retired without downtime.

New device, new passkey, passkey removed, PIN changed, recovery codes changed and recovery started all raise an alert. Each one carries the device and the time — never an IP address, never a location.

There is no code path without PKCE, and S256 is the only accepted method. A missing challenge, an empty challenge, or a plain challenge is refused rather than downgraded.

Access tokens and ID tokens are ES256-signed and carry a key id, advertised through an OpenID Connect discovery document and a JWKS endpoint you can cache.

A consent screen, a scope catalogue with per-app scope grants, and a connected-apps list where a person can take an application’s access away again.

For input-constrained devices: a device code, a short user code, and an approval screen on a phone or laptop.

Revoke a token immediately, or introspect one server-side to check that it is still live.

An official plugin that wires a WordPress login screen to the OAuth and OIDC endpoints, so a site can go passwordless without writing OAuth code.

The password and password-reset tables were dropped outright. There is no stored hash to breach, no reset email to intercept, and no code path that would accept a password if one were offered.

ES256, RS256 and EdDSA credentials, discoverable by default, so a returning person can sign in without typing anything first.

Packed, TPM, Android Key, Android SafetyNet, Apple and FIDO U2F attestation statements are all verified, with optional enforcement against the FIDO Metadata Service for deployments that need to restrict authenticator models.

Cross-device sign-in over the platform hybrid transport, for the laptop that has never seen your passkey.

List your passkeys with their nickname, transports and authenticator model, and revoke any one of them.

Sign-up proves ownership of an email address and a WhatsApp number before a credential is created. The one-time code proves the channel — it is never a login factor.

A second factor for people who want one, stored as an argon2 hash with attempt limits and a lockout.

The account constraint still demanded an email address or a phone number, which meant a passkey-only account was rejected. A WebAuthn user handle is now a valid identifier on its own.

See every active session, revoke one, or revoke all of them — plus login history and recent account activity.

Create and delete your own API keys for scripting against your account.

A separate service for writing and querying audit events, with statistics and an event-type catalogue.

An account can link Google, Apple, Facebook, GitHub, Microsoft, Discord, LinkedIn or Slack, for people arriving from somewhere else.

Document submission with machine-readable-zone parsing and a human review step before anything is marked verified.

A control-plane command-line tool covering every Paswad service, with an interactive shell and machine-readable JSON output.