Sign In

1. Register your application

In the Developer Panel, click Register Application and give it a name plus one or more exact redirect URIs — the page on your site that Wmail is allowed to send users back to (e.g. https://myapp.com/auth/wmail/callback). You'll get a client_id (public, safe to put in frontend code) and a client_secret (private — keep it on your server only, shown once). Wmail will refuse to redirect anywhere that isn't on this exact list, so double- and triple-check it before saving.

2. Send the user to Wmail to sign in

Redirect the browser to the login page with your client_id, the exact redirect_uri you registered, and a random state value (store it, e.g. in a cookie, so you can check it matches on the way back — this stops cross-site request forgery on your callback).

3. User signs in and approves

The user logs into their Wmail identity as usual, then sees a consent screen naming your app and exactly what it will receive (name + email). Only after they click Allow does Wmail redirect back to your redirect_uri with a short-lived, single-use code and your state value attached as query parameters.

4. Exchange the code for the user's identity — from your server

On your callback route, first check that state matches what you stored in step 2. Then call the token endpoint from your backend (never from the browser — this is the one call that needs your client_secret):

Security notes

• redirect_uri must match exactly what you registered — no wildcards, no "starts with" matching. If you need another environment (staging, localhost), register it as a separate URI.
• client_secret is a server-side secret. Never bundle it into frontend JavaScript, mobile apps, or a public repo.
• The authorization code is single-use and expires after 2 minutes — always exchange it immediately in your callback handler.
• Always verify the state parameter on your callback before trusting the response.