- Installation and updates
- Sending your first request
- Creating the first collection
- Navigating Postman
- Keyboard Shortcuts
- Postman account
- New button
- Troubleshooting In-app Issues
- Customizing Postman
- Find and Replace
- Troubleshooting API requests
- Debugging and logs
- Authorizing requests
- Capturing HTTP requests
- Generate code snippets
- Making SOAP requests
- Working with Tabs
- Using GraphQL
- Visualize API responses
- Intro to collections
- Creating collections
- Sharing collections
- Managing collections
- Requesting access
- Using Markdown for descriptions
- Data formats
- Working with OpenAPI
- Commenting on collections
- Version Control for Collections
- Intro to scripts
- Pre-request scripts
- Test scripts
- Test examples
- Branching and looping
- Postman Sandbox
- Postman Sandbox API reference
- Intro to collection runs
- Starting a collection run
- Using environments in collection runs
- Working with data files
- Running multiple iterations
- Building workflows
- Sharing a collection run
- Debugging a collection run
- Command line integration with Newman
- Integration with Jenkins
- Integration with Travis CI
- Newman with Docker
- Documenting your API
- Viewing documentation
- Authoring your documentation
- Publishing your docs
- Custom documentation domains
- Intro to Monitoring
- Setting up a monitor
- Viewing monitor results
- Monitoring APIs and websites
- Set up integrations to receive alerts
- Pricing for monitors
- Troubleshooting monitors
- FAQs for monitors
- Intro to mock servers
- Setting up a mock server
- Mocking with examples
- Mocking with the Postman API
- Matching algorithm
- Introduction to APIs
- Managing APIs
- Sharing APIs and managing roles
- The API Workflow
- Validating Elements Against Schema
- Versioning APIs
- Reporting FAQs
- Viewing and analyzing APIs
- Intro to Workspaces
- Creating Workspaces
- Managing Workspaces
- Using Workspaces
- Sharing collections in Workspaces for version 5
- Viewing changelogs and restoring collections
- What is Postman Pro
- Purchasing Postman Pro
- Upgrading to Postman Pro from a trial team
- Team Settings
- Changing your plan
- Managing your team
- Migrating to Postman v7
- Roles and permissions
- Intro to Enterprise
- Purchasing Postman Enterprise
- Running Postman monitors using static IPs
- Intro to SSO
- Configuring SSO for a team
- Logging in to an SSO team
- Configuring Microsoft AD FS with Postman SSO
- Setting a custom SAML in Azure AD
- Setting up custom SAML in Duo
- Setting up custom SAML in GSuite
- Setting up custom SAML in Okta
- Setting up custom SAML in Onelogin
- Setting up custom SAML in Ping Identity
- Audit logs
- Publishing API documentation
APIs use authorization to ensure that client requests access data securely. This can involve authenticating the sender of a request and verifying that they have permission to access or manipulate the relevant data. If you're building an API, you can choose from a variety of auth models. If you're integrating a third-party API, the required authorization will be specified by the API provider.
You can pass auth details along with any request you send in Postman. Auth data can be included in the header, body, or as parameters to a request. If you enter your auth details in the Authorization tab, Postman will automatically populate the relevant parts of the request for your chosen auth type. You can use variables and collections to define authorization details more safely and efficiently, letting you reuse the same information in multiple places.
- Syncing cookies
- Next steps
With a request open in Postman, use the Authorization tab Type dropdown to select an auth type. Postman will prompt you to complete the relevant details for your selected type. The correct data values will be determined by your API at the server side—if you're using a third party API you will need to refer to the provider for any required auth details.
You can use these auth types with Newman and Postman monitors as well as in the app.
When you select a type, Postman will indicate which parts of the request your details will be included in, for example the header, body, URL, or query parameters. Click Preview Request to see how your auth data will be added to the request before attempting to send it.
Your auth data will appear in the relevant parts of the request, for example appended to text in the header using the standard formats your API will be able to process.
Your requests can use environment, collection, and global variables. Postman does not save header data or query parameters to avoid exposing sensitive data such as API keys.
You can inspect a raw dump of the entire request including auth data in the Postman console after you send it.
Select a collection or folder in Collections on the left of the Postman app. Use the overflow button (...) to open the options and select Edit to configure the collection or folder detail.
In the edit view, select the Authorization tab.
By default, requests inside the collection or folder will inherit auth from the parent, which means that they'll use the same auth that you've specified at the folder or collection level. To change this for an individual request, make a different selection in the request Authorization tab.
You can choose an authorization type upfront using the same technique when you first create a collection or folder.
Postman will not attempt to send authorization details with a request unless you specify an auth type. If your request does not require authorization, select No Auth from the Authorization tab Type dropdown list.
Bearer tokens allow requests to authenticate using an access key, such as a JSON Web Token (JWT). The token is a text string, included in the request header. In the request Authorization tab, select Bearer Token from the Type dropdown list. In the Token field, enter your API key value—or for added security, store it in a variable and reference the variable by name.
Postman will append the token value to the text "Bearer " in the required format to the request Authorization header as follows:
Bearer <Your API key>
Basic authentication involves sending a verified username and password with your request. In the request Authorization tab, select Basic Auth from the Type dropdown list.
Enter your API login details in the Username and Password fields—for additional security you can store these in variables.
Click Preview Request to see how Postman will append your basic auth details to the request. In the request Headers, you will see that the Authorization header is being passed a Base64 encoded string representing your username and password values, appended to the text "Basic " as follows:
Basic <Base64 encoded username and password>
With Digest auth, the client sends a first request to the API, and the server responds with a few details, including a number that can be used only once (nonce), a realm value, and a
401 unauthorized response. You then send back an encrypted array of data including username and password combined with the data received from the server in the first request. The server uses the passed data to generate an encrypted string and compares it against what you sent in order to authenticate your request.
In the Authorization tab for a request, select Digest Auth from the Type dropdown list. Postman will present fields for both stages of authentication request—however it will autocomplete the fields for the second request using data returned from the server by the first request. To allow Postman to automate the flow, enter Username and Password values (or variables) and these will be sent with the second request.
If you don't want Postman to automatically extract the data, check the box to disable retrying the request. If you do this, you will need to complete the advanced fields and run each request manually.
The advanced fields are optional, and Postman will attempt to populate them automatically when your request runs.
- Realm: A string specified by the server in the
- Nonce: A unique string specified by the server in the
- Algorithm: A string that indicates a pair of algorithms used to produce the digest and a checksum.
- qop: The quality of protection applied to the message. The value must be one of the alternatives specified by the server in the
- Nonce Count: The hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request.
- Client Nonce: An opaque quoted string value provided by the client, used by both client and server to avoid chosen plaintext attacks, to provide mutual authentication, and to provide some message integrity protection.
- Opaque: A string of data specified by the server in the
WWW-Authenticateresponse header, which should be used unchanged with URIs in the same protection space.
OAuth 1.0 allows client applications to access data provided by a third-party API. For example, as a user of a service you can grant another application access to your data with that service without exposing your login details. Accessing user data via the OAuth 1.0 flow involves a few requests back and forth between client application, user, and service provider.
OAuth 1.0 is sometimes referred to as "two-legged" (auth only between client and server) or "three-legged" (where a client requests data for a user of a third-party service).
- To request user data with a third-party service, a consumer (client application) requests an access token using a key and secret.
- The service provider issues an initial token (that doesn't provide access to user data) and the consumer requests authorization from the user.
- When the user grants auth, the consumer makes a request to exchange the temporary token for an access token, passing verification from the user auth.
- The service provider returns the access token and the consumer can then make requests to the service provider to access the user's data.
In the Authorization tab for a request, select OAuth 1.0 from the Type dropdown list.
Enter your Consumer Key, Consumer Secret, Access Token, and Token Secret values. You can optionally set advanced details—otherwise Postman will attempt to autocomplete these.
You can include the auth details either in the request headers or in the body / URL—select one from the dropdown list. Click Preview Request if you want to check how the details will be included with the request.
If you send the OAuth 1.0 data in the headers, you will see an Authorization header sending your key and secret values appended to the string " OAuth " together with additional comma-separated required details.
If you send the OAuth 1.0 data in the body and URL, you will find the data added either in the request Body or Parameters depending on the request method.
If the request method is
PUT, and if the request body type is
x-www-form-urlencoded, Postman will add the authorization parameters to the request body. Otherwise, for example in a
GET request, your key and secret data will be passed in the URL query parameters.
The OAuth 1.0 auth parameter values are as follows:
- Consumer Key: A value used to identify a consumer with the service provider.
- Consumer Secret: A value used by the consumer to establish ownership of the key.
- Access Token: A value representing the consumer's permission to access the user's data.
- Token Secret: A value used by the consumer to establish ownership of a given token.
- Signature Method: A consumer secret that establishes ownership of a given token.
- Time Stamp: The timestamp the server uses to prevent replay attacks outside the time window.
- Nonce: A random string generated by the client.
- Version: The version of the OAuth authentication protocol (1.0).
- Realm: A string specified by the server in the
Some implementations of OAuth 1.0 require empty parameters to be added to the signature. Check the Add empty parameters to signature checkbox if you need this.
OAuth 1.0 allows client applications to access data provided by a third-party API. For example, as a user of a service you can grant another application access to your data with that service without exposing your login details. With OAuth 2.0, you first retrieve an access token for the API, then use that token to authenticate future requests. Accessing data via the OAuth 2.0 flow varies greatly between API service providers, but typically involves a few requests back and forth between client application, user, and API.
An example OAuth 2.0 flow could run as follows:
- A client application makes a request for the user to authorize access to their data.
- If the user grants access, the application then requests an access token from the service provider, passing the access grant from the user and authentication details to identify the client.
- The service provider validates these details and returns an access token.
- The client uses the access token to request the user data via the service provider.
In the Authorization tab for a request, select OAuth 2.0 from the Type dropdown list. Specify whether you want pass the auth details in the request URL or headers.
To request an access token, click Get New Access Token.
Enter the details for your client application, and any auth details from the service provider. This allows you to replicate your application auth flow inside Postman in order to test authenticated requests.
Authorization code grant type requires the user to authenticate with the provider—an authorization code is then sent back to the client app, extracted, and exchanged with the provider for an access token to authenticate subsequent requests.
To use Authorization code grant type, enter a Callback URL for your client application (which should be registered with the API provider), together with various details provided by the API service including Auth URL, Access Token URL, Client ID, and Client Secret.
Implicit grant type returns an access token to the client straight away without requiring the additional auth code step (and is therefore less secure).
To use implicit grant type with your requests in Postman, enter a Callback URL you have registered with the API provider, the provider Auth URL, and a Client ID for the app you have registered.
OAuth 2.0 Password grant type involves sending username and password directly from the client and is therefore not recommended if you're dealing with third-party data.
To use password grant type, enter your API provider's Access Token URL, together with the Username and Password. In some cases you will also need to provide a client ID and secret.
Client credentials grant type is typically not used to access user data but instead for data associated with the client application.
Enter the provider's Access Token URL, together with the Client ID and Client Secret for your registered application.
The full list of parameters to request a new access token is as follows, depending on your grant type:
- Token Name: The name you want to use for the token.
- Grant Type: A dropdown list of options—this will depend on the API service provider requirements.
- Callback URL: The client application callback URL redirected to after auth, and that should be registered with the API provider. If not provided, Postman will use a default empty URL and attempt to extract the code or access token from it—if this does not work for your API, you can use the following URL:
- Auth URL: The endpoint for the API provider authorization server, to retrieve the auth code.
- Access Token URL: The provider's authentication server, to exchange an authorization code for an access token.
- Client ID: The ID for your client application registered with the API provider.
- Client Secret: The client secret given to you by the API provider.
- Scope: The scope of access you are requesting, which may include multiple space-separated values.
- State: An opaque value to prevent cross-site request forgery.
- Client Authentication: A dropdown—send a Basic Auth request in the header, or client credentials in the request body. After upgrading to a new version, change the value in this dropdown menu to avoid problems with client authentication.
When your config is complete, click Request Token. If you successfully receive a token from the API you will see its details, together with the expiry, and optionally a refresh token you can use to retrieve a new access token when your current one expires. Click Use Token to select the returned value.
Any successfully retrieved tokens will be listed in the request Available Tokens dropdown list. Select one to send with your request. Select Manage Tokens in the dropdown list to view more details or delete your tokens.
Deleting a token in Postman does not revoke access. Only the server that issues the token can revoke it.
Hawk authentication enables you to authorize requests using partial cryptographic verification.
In the Authorization tab for a request, select Hawk Authentication from the Type dropdown list.
Enter your details in the Hawk Auth ID, Hawk Auth Key, and Algorithm fields. You can optionally set advanced details, but Postman will attempt to generate values for them if necessary.
The Hawk Authentication parameters are as follows:
- Hawk Auth ID: Your API authentication ID value.
- Hawk Auth Key: Your API authentication key value.
- Algorithm: The hash algorithm used to create the message authentication code (MAC).
- User: The username.
- Nonce: A random string generated by the client.
- ext: Any application-specific information to be sent with the request.
- app: The binding between credentials and the application to prevent an attacker using credentials issued to someone else.
- dlg: The ID of the application the credentials were issued to.
- Timestamp: Timestamp the server uses to prevent replay attacks outside the time window.
AWS is the authorization workflow for Amazon Web Services requests. AWS uses a custom HTTP scheme based on a keyed-HMAC (Hash Message Authentication Code) for authentication.
The official AWS Signature documentation provides more detail:
In the Authorization tab for a request, select AWS Signature from the Type dropdown list.
Enter your access key and secret values either directly in the fields or via variables for additional security.
You can optionally set advanced fields, but Postman will attempt to autogenerate these if necessary.
The AWS Signature parameters are as follows:
- AWS Region: The region receiving the request (defaults to
- Service Name: The service receiving the request.
- Session Token: Required only when using temporary security credentials.
Windows Challenge/Response (NTLM) is the authorization flow for the Windows operating system and for standalone systems.
In the Authorization tab for a request, select NTLM Authentication from the Type dropdown list.
Enter your Username and Password for NTLM access (use variables to avoid entering the values directly). You can optionally specify advanced parameters, but Postman will attempt to autocomplete these if necessary. By default your request will run a second time after extracting data received from the first—you can disable this by checking the checkbox.
Advanced parameters for NTLM auth are as follows:
- Domain: The domain or host to authenticate against.
- Workstation: The hostname of the PC.
Akamai Edgegrid is an authorization helper developed and used by Akamai.
In the Authorization tab for a request, select Akamai EdgeGrid from the Type dropdown list.
Enter your Access Token, Client Token, and Client Secret, using variables for additional security—you will receive these details when you register a client application with Akamai.
For information on obtaining your credentials, see Akamai Developer - Authorize your Client.
If you're having issues getting a request to authenticate and run successfully, try some of the tips in troubleshooting API requests. If you still have auth problems, check out the authentication tag on the Postman forum.