Looking for Postman, the WordPress mailer with OAuth support? That is a different product called Post SMTP, covered separately under Post SMTP Mailer (aka Postman SMTP). This piece is about Postman, the API platform at postman.com, used as a client when calling OAuth-secured APIs.
What Postman actually does in an OAuth flow
Postman is an OAuth 2.0 client. It handles the redirect dance with an identity provider, exchanges the resulting authorization code for an access token, stores that token, and attaches it to subsequent requests as a Bearer header. It is not an identity provider, it is not a server-side application running in production, and it is not a credential store fit for sharing across a team without thought. It is the convenient place to obtain a token and confirm that a protected endpoint accepts it before wiring the same configuration into something else.
That something else is often a WordPress SMTP mailer connecting to Microsoft 365 or Gmail via XOAUTH2. The pattern: register an application in the IdP, validate the registration by getting a token in Postman, then transcribe the same client ID, secret, and scopes into the mailer plugin. If the token works in Postman and fails in the plugin, the problem is almost always scope, not credentials. The walkthroughs below assume this kind of use.
Grant types Postman supports, and when each is right
Postman’s Authorization tab lists six OAuth 2.0 entries. Only two of them are worth reaching for in 2026.
Authorization Code with PKCE. The default choice for any user-delegated flow. Works against Microsoft Entra ID, Google, Auth0, Okta, GitHub, and every modern IdP. PKCE (RFC 7636) is recommended even for confidential clients because it removes a class of code-interception attacks; Postman generates the verifier and challenge automatically when "Code Challenge Method" is set to SHA-256.
Client Credentials. The right choice when there is no user, only a service. Microsoft Graph application permissions, Google service accounts (with caveats), and most internal IdP machine-to-machine flows use this. The token is bound to the application itself, not a user.
Implicit and Password. Both are deprecated by the OAuth 2.0 Security Best Current Practice (RFC 9700) and should not be used for new integrations. They remain in the dropdown for compatibility with legacy systems; pick them only when the IdP gives no other option.
Device Authorization. Useful for headless or input-constrained clients. Postman supports it but the use case rarely intersects with a desktop developer’s workflow.
The redirect URI is where most setups fail
Postman uses a fixed callback URL by default: https://oauth.pstmn.io/v1/callback. That URL must be registered as a redirect URI on the IdP’s application record. The single most common cause of a failed OAuth flow in Postman is forgetting this step, which produces AADSTS50011: The redirect URI specified in the request does not match from Microsoft, or Error 400: redirect_uri_mismatch from Google.
The first option is to register https://oauth.pstmn.io/v1/callback on the IdP. This works for any tenant that allows the public Postman callback as a redirect URI. Some enterprise IdPs prohibit external callbacks; in those cases the second option is required.
The second is to toggle "Authorize using browser" in Postman’s OAuth 2.0 settings. With this on, Postman opens the system browser to handle the authorization redirect. The redirect URI Postman uses in this mode is shown in the Callback URL field once the toggle is enabled. Copy that value into the IdP’s registered redirect URIs before attempting the flow. On macOS and Linux the Postman desktop agent must be installed and running for the callback to be intercepted; the web app cannot receive a redirect from an external browser.
Pick the public callback for personal IdP tenants and dev environments. Pick the browser flow for tenants where the security team has locked redirect URIs to corporate domains.
Walkthrough: Authorization Code with PKCE against Microsoft Graph
The example below targets Microsoft Graph because most WordPress operators arriving at this page do so en route to configuring Microsoft 365 SMTP via OAuth. The same pattern works against any modern IdP with the appropriate endpoint URLs.
Prerequisites: an Entra ID application registration with the Postman callback URL registered as a redirect URI, the application’s client ID and client secret to hand, and either delegated or application Microsoft Graph permissions granted to the app.
In Postman, open a request that targets https://graph.microsoft.com/v1.0/me, switch to the Authorization tab, and pick OAuth 2.0 as the type. Fill in:
- Token Name: any label, for example
graph-delegated-token - Grant Type:
Authorization Code (With PKCE) - Callback URL:
https://oauth.pstmn.io/v1/callback, with "Authorize using browser" unchecked - Auth URL:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize, replacing{tenant}with the tenant ID orcommonfor multi-tenant - Access Token URL:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token - Client ID: from the Entra ID application registration
- Client Secret: the secret value (not the secret ID) from the registration
- Code Challenge Method:
SHA-256 - Code Verifier: leave blank; Postman generates one
- Scope:
https://graph.microsoft.com/.defaultfor the full set granted to the app, or specific scopes such asMail.Send User.Read offline_access - State: leave blank or set a value; Postman validates the round trip
- Client Authentication:
Send as Basic Auth headerfor most Entra ID configurations
Click "Get New Access Token". A browser window opens, the IdP authenticates the user and prompts for consent, and Postman receives the access token and refresh token. The token appears in the dialog with its expiry; clicking "Use Token" sets it on the current request.
A 200 from https://graph.microsoft.com/v1.0/me confirms the registration is correct. Transcribe the same client ID, secret, and scope into WP Mail SMTP, FluentSMTP, or any other consumer that needs a Graph token.
Walkthrough: Client Credentials for machine-to-machine
For application-only access, where the app is the principal and no user delegates permissions, only the token endpoint and client credentials are needed.
- Grant Type:
Client Credentials - Access Token URL:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token - Client ID and Client Secret: as before
- Scope:
https://graph.microsoft.com/.default - Client Authentication:
Send as Basic Auth header
No browser redirect happens; Postman makes a server-to-server call to the token endpoint and returns the token. Useful for testing application permissions, daemon services, and any flow where the app is the principal.
A token obtained this way carries application permissions only, not delegated ones. A request to https://graph.microsoft.com/v1.0/me will return 403 Forbidden because there is no user context; use https://graph.microsoft.com/v1.0/users/{id} instead.
Storing and reusing tokens
Postman scopes OAuth configuration at three levels: the individual request, the folder, and the collection. Authorization set at a collection level is inherited by every request inside it, unless the request or folder overrides. For a Graph-based collection, configuring OAuth 2.0 at the collection level and leaving every request set to "Inherit auth from parent" is the right default.
Tokens obtained through "Get New Access Token" are stored in Postman’s vault and listed under "Available Tokens" on the Authorization tab. Each token shows its expiry. Postman does not automatically refresh tokens when they expire; the next request after expiry fails with a 401, and the user clicks "Get New Access Token" again or, if the IdP issued a refresh token, "Refresh Token".
To use the same access token across multiple requests or environments without copying it manually, set it as a Postman environment variable. After obtaining the token, copy its value into a variable called access_token on the active environment. Any request that uses {{access_token}} in its Authorization header receives the current value. Combined with collection-level inheritance, this is the cleanest way to thread one token through dozens of test requests.
Common failures, named precisely
These errors show up most often when validating a Microsoft 365 or Google OAuth registration in Postman.
AADSTS50011: The redirect URI specified in the request does not match. The Entra ID application registration does not list the Postman callback URL as a redirect URI of type "Web" or "Single-page application". Fix on the Azure side.
invalid_client. Most commonly: the client secret value is wrong, or the secret has expired, or the secret was sent in the request body when the IdP expects HTTP Basic. Switch "Client Authentication" between "Send as Basic Auth header" and "Send client credentials in body" and try again.
invalid_scope or AADSTS70011: The provided value for the input parameter 'scope' is not valid. Common causes: mixing Graph delegated scopes (Mail.Send) with the .default form in one request; requesting a scope the app does not have permission for; or missing admin consent on an application permission.
interaction_required or AADSTS50076. Conditional access policy on the tenant requires multi-factor or a managed device. The flow cannot complete without the policy being satisfied; this is a tenant configuration matter, not a Postman one.
AADSTS65001: The user or administrator has not consented. An admin needs to grant tenant-wide consent for the requested scopes, or the user needs to be prompted with prompt=consent. Add prompt=consent under "Auth Request Parameters" in Postman to force the consent screen.
Token works in Postman, fails in WordPress mailer or in msmtp. The downstream consumer expects a different scope. Microsoft 365 SMTP AUTH requires the scope https://outlook.office.com/SMTP.Send, which is different from Graph’s Mail.Send. A token issued with Graph scopes will be rejected by the SMTP submission service even though it works fine against Graph endpoints. The fix is to obtain a separate token with the SMTP.Send scope, or to switch the integration to use Graph’s sendMail endpoint instead of SMTP submission.
One tip worth keeping
Store the token in an environment variable, not in the Authorization tab. Configuring {{access_token}} as a Bearer header at the collection level and updating the variable when the token rotates is more maintainable than re-clicking "Use Token" on every request. It also makes the same collection portable between developers without sharing the token itself, provided the environment is excluded from any export.