Skip to main content

API Authentication, Endpoints, and Security


This guide describes API authentication and the Sumo Logic endpoints to use for your API client.

Sumo Logic APIs follow Representational State Transfer (REST) patterns and are optimized for ease of use and consistency. Our interactive API docs have been developed with the OpenAPI Specification, unless otherwise stated. The API docs on this site serve as supplemental information.

To view our main docs, click the link below corresponding to your deployment. If you're not sure, see How to determine your endpoint.

DeploymentAPI Docs URL


Sumo Logic supports the following options for API authentication:

  • Access ID and access key
  • Base64-encoded access id and access key

See Access Keys to learn how to generate an access key. Make sure to copy the key you create, because it is displayed only once.

Access ID and Access Key

When you have an accessId and accessKey, you can execute requests like the following:

curl -u "<accessId>:<accessKey>" -X GET <API Endpoint>

Where <API Endpoint> is the Sumo Logic API URL you're sending requests to. For more information, see Sumo Logic Endpoints.

Basic Access (Base64 encoded)

If you prefer to use basic access authentication, you can do a Base64 encoding of your <accessId>:<accessKey> to authenticate your HTTPS request. The following is an example request. Replace the placeholder <encoded> with your encoded access id and access key string:

curl -H "Authorization: Basic <encoded>" -X GET <API Endpoint>

The spacing in the Authorization field is required.

Base64 example

In most Linux distributions, you can use the base64 command. As an example, if your access id is Aladdin and your access key is OpenSesame, then the command would be as follows:

echo -n "Aladdin:OpenSesame" | base64 --wrap 0

The -n ensures that an extra newline is not encoded.

This would yield a Base64 encoded string QWxhZGRpbjpPcGVuU2VzYW1l that is used like this:

"Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l"

Sumo Logic Endpoints by Deployment and Firewall Security


Sumo Logic has several deployments that are assigned depending on the geographic location and the date an account is created.

Sumo Logic redirects your browser to the correct login URL and also redirects Collectors to the correct endpoint. However, if you're using an API you'll need to manually direct your API client to the correct Sumo Logic API URL.

DeploymentService Endpoint (login URL)API EndpointCollection EndpointCloud Syslog EndpointOpenTelemetry Collector Endpoint

Which endpoint should I should use?

To determine which endpoint you should use, you'll need to find your account's deployment pod, which is located in the Sumo Logic URL you use. If you see us2, that means you're running on the US2 pod. If you see eu, jp, de, in, ca, or au, you're on one of those pods. The only exception is the US1 pod, which uses

The specific collection endpoint will vary per account. The general format is: endpoint[N].collection.[deploymentID]

You can also determine which deployment pod your account is using by creating an HTTP Source and looking at the provided URL.

Securing access to Sumo Logic infrastructure via DNS name or IP address

See the static IP addresses for Cloud-to-Cloud Integration Sources.

For collection to work, your firewall must allow outbound traffic to Sumo Logic. Refer to Test Connectivity for Sumo Logic Collectors for instructions on allowing outbound traffic over port 443.

  • If your firewall allows DNS entries, add the following to the allowlist in your firewall to allow outbound traffic to
    • By default, the Collector contacts before it is redirected to a deployment-specific endpoint such as and endpoint[N].collection.[deploymentID].[].
  • If your firewall doesn’t allow DNS entries, you must allowlist all of the IP addresses for your deployment region. The addresses to allowlist depend on your Sumo Logic deployment.
    • To determine the IP addresses that require allowlisting, download the JSON object provided by Amazon Web Services (AWS). Amazon advises that this file will change several times a week. For details on how the file is updated, its usage, its syntax, and how to download the JSON file, see AWS IP Address Ranges.

FedRAMP Deployment

Sumo Logic's FedRAMP deployment is similar to our other deployments, such as US2, except that FedRAMP is certified to comply with the United States Standards for Security Categorization of Federal Information and Information Systems (FIPS-199). In this deployment, we adhere to specific security requirements that are required for handling, storing, and transmitting data classified in the "Moderate" impact level.

AWS Region by Sumo Deployment

The following table describes the AWS regions used by each Sumo Logic deployment. See the AWS page on regions and endpoints for more information.

Sumo DeploymentAWS Region NameAWS Region
AUAsia Pacific (Sydney)ap-southeast-2
CACanada (Central)ca-central-1
DEEU (Frankfurt)eu-central-1
EUEU (Ireland)eu-west-1
FEDUS East (N. Virginia)us-east-1
INAsia Pacific (Mumbai)ap-south-1
JPAsia Pacific (Tokyo)ap-northeast-1
US1US East (N. Virginia)us-east-1
US2US West (Oregon)us-west-2

This link provides the complete current list of AWS IP ranges or subnets or prefixes. You can limit the number of entries in a firewall by using just the IP prefixes against the AWS region that your account's Sumo deployment uses, as shown in the table.

The list of IP ranges is shared infrastructure. It is not limited to Sumo Logic nodes and is subject to change over time.

You can run the following query against the downloaded file in Sumo Logic to determine the IP addresses for each deployment.

| parse regex "\s+\"ip_prefix\":\s+\"(?<ip_prefix>.*?)\",\n\s+\"region\":\s+\"(?<region>.*?)\",\n\s+\"service\":\s+\"(?<service>.*?)\"" multi | where service="AMAZON" and (region="us-west-2" or region="us-east-1" or region="eu-west-1" or region="ap-southeast-2") | if (region="us-west-2", "US2", region) as region | if (region="us-east-1", "PROD", region) as region | if (region="eu-west-1", "EU", region) as region | if (region="ap-southeast-2", "AU", region) as region | count by ip_prefix, region, service | fields - _count | sort by region, ip_prefix

After configuring the firewall, Collector, and Sources, confirm that the Collector and Sources are working by verifying that you can receive a given type of message (such as syslog messages) at the specified location.

Status Codes

Generic status codes that apply to all our APIs. See the HTTP status code registry for reference.

HTTP Status CodeError CodeDescription
301movedThe requested resource SHOULD be accessed through returned URI in Location Header. See troubleshooting for details.
401unauthorizedCredential could not be verified.
403forbiddenThis operation is not allowed for your account type or the user doesn't have the role capability to perform this action. See troubleshooting for details.
404notfoundRequested resource could not be found.
405method.unsupportedUnsupported method for URL.
415contenttype.invalidInvalid content type.
429rate.limit.exceededThe API request rate is higher than 4 request per second or in-flight API requests are higher than 10 request per second.
500internal.errorInternal server error.
503service.unavailableService is currently unavailable.

Rate limiting

  • A rate limit of four API requests per second (240 requests per minute) applies to all API calls from a user.
  • A rate limit of 10 concurrent requests to any API endpoint applies to an access key.

If a rate is exceeded, a rate limit exceeded 429 status code is returned.

Versioning and Conflict Detection

The Collector Management API uses optimistic locking to deal with versioning and conflict detection. Any response that returns a single entity will have an ETag header which identifies the version of that entity.

Subsequent updates (PUT requests) to that entity must provide the value of the ETag header in an If-Match header; if the header is missing or no longer corresponds to the latest version of the entity, the request will fail (with 403 Forbidden or 412 Precondition Failed, respectively).

Clients must be prepared to handle such failures if they anticipate concurrent updates to the entities. Additionally, the value of the ETag header may be provided in an If-None-Match header in future GET requests for caching purposes.

Sumo Logic alerts from static IP addresses

Sumo Logic provides notifications through static IP addresses. You can allowlist those IP addresses to receive notifications directly from Sumo. For a list of our allowlist addresses, contact Support.

The Test Connection feature for webhooks does not use the same static IP addresses that send notifications, it uses different temporary IP addresses.

Privacy Statement
Terms of Use

Copyright © 2024 by Sumo Logic, Inc.