Content review: Long-form content

    This guide explains what an API token is, why you need one, and how to create one.

    **Note**: For enhanced security, [VENDOR] strongly recommends using the OAuth 2.0 authentication scheme with [VENDOR] APIs rather than relying on the [VENDOR]-propriety [AUTH SCHEME] API token scheme. OAuth 2.0 improves security by employing short-lived access tokens that limit the scope of granted access. See Set up [VENDOR] for OAuth API access. 
    <Note>For enhanced security, [VENDOR] recommends using the OAuth 2.0 authentication scheme with [VENDOR] APIs rather than the [VENDOR]-proprietary [AUTH SCHEME] API token scheme. OAuth 2.0 uses short-lived access tokens that limit the scope of access. See Set up [VENDOR] for OAuth API access.</Note>

    ## Learning outcomes
    - Learn how a [VENDOR] API token is used. 
    - Understand why it's good practice to create a service account for use with an API token. 
    - Know the alternatives to [VENDOR] API tokens. 
    - Find out when a token expires and what happens when it expires. 
    - Find out how API tokens are deactivated. 
    - Understand how [VENDOR] API tokens work. 
    - Understand when and why to use a service account with an API token. 
    - Understand token expiration and deactivation behavior. 

    ## What you need
    A [VENDOR] org

    ## [VENDOR] API tokens 
    [VENDOR] API tokens are used to authenticate requests to [VENDOR] APIs. When calling a [VENDOR] API endpoint, you need to supply a valid API token in the HTTP `Authorization` header, with a valid token specified as the header value. You need to prefix the value with the [AUTH SCHEME] identifier, which specifies the proprietary authentication scheme that [VENDOR] uses. For example: 
    ## Overview 
    [VENDOR] API tokens authenticate requests to [VENDOR] APIs. When you call a [VENDOR] API endpoint, include a valid API token in the HTTP `Authorization` header using the [AUTH SCHEME] scheme. For example: 

    `Authorization: [AUTH SCHEME] 00QCjAl4MlV-WPXM...0HmjFx-vbGua`

    ## Privilege level
    Different [VENDOR] API operations require different admin privilege levels. API tokens inherit the privilege level of the admin account that is used to create them. However, if the admin's privileges are modified, the privilege level of the API token changes to match the new level of the admin. It's therefore good practice to create a service account to use when you create API tokens. With a separate service account, you can assign specific privilege levels to your API tokens. See Administrators for admin account types and the specific privileges of each. 
    API tokens inherit the privilege level of the admin account used to create them. If the admin's privileges change, the token's privileges automatically change to match the new level of the admin. To keep token privileges independent of admin accounts, [VENDOR] recommends creating a dedicated service account for generating API tokens. With a separate service account, you can assign specific privilege levels to your API tokens. See Administrators for admin account types and privilege levels. 

    ## OAuth 2.0 instead of API tokens 
    As an alternative to [VENDOR] API tokens, you can use a scoped OAuth 2.0 access token for various [VENDOR] endpoints. Each access token enables the bearer to perform specific actions on specific [VENDOR] endpoints, with that ability controlled by which scopes the access token contains. For more information, see the OAuth for [VENDOR] guide. 

    ## Create the token
    See Create [VENDOR] API tokens to create an API token and define the network zones that API calls can originate from.

    > **Note**: Record the token value. This is the only opportunity to see it and record it. 
    <Note>The only time you can view and copy the token is during the creation process. After the token is created, it's stored as a hash for your protection. [VENDOR] recommends that you treat API tokens like passwords.</Note>

    ## Token network restrictions
    You can specify a network range for every [AUTH SCHEME] API token. The tokens only work if API requests are made from the specified IP or network range. You can specify network zones while you create an API token. You can also modify an existing token to specify a network range. 
    You can specify a network range for each API token. The tokens only work when API requests originate from the specified IP address or network range. You can define network zones when you create or modify an API token. 

    See Manage [VENDOR] API tokens for steps on creating API tokens and editing network restrictions for an existing API token.

    ## Token rate limits
    When API tokens are created, the rate limit for each token interaction is set automatically to 50 percent of each API maximum limit. See API rate limits. You can adjust this percentage by editing the Token rate limits section. See Set token rate limits. 
    Each API token defaults to 50 percent of the maximum rate limit per API. You can adjust this percentage in the **Token rate limits** section. See Set token rate limits and API rate limits. 

    ## Token expiration and deactivation
    Tokens expire automatically after a certain period and can also be deactivated at any time. 
    Tokens expire automatically and can be deactivated manually. 

    ### Token expiration
    Tokens are valid for 30 days from creation or last use, so that the 30 day expiration automatically refreshes with each API call. Tokens that aren't used for 30 days expire. The 30-day period is fixed and can't be changed for your org. 
    Tokens are valid for 30 days from creation or last use. Each successful API call resets the 30-day expiry timer. You can't change this expiry period. 

    ### Token deactivation
    If a user account is deactivated in [VENDOR], any API token created by that user account is deprovisioned at the same time. 
    If a user account is deactivated in [VENDOR], all API tokens created by that account are deprovisioned at the same time. 

    ## Next steps
    With the token created, you can begin using it, supplying it in the `Authorization header` of calls to [VENDOR] API endpoints. 
    Include the API token in the `Authorization` header of calls to [VENDOR] API endpoints.