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.
Documentationβ
To view our main docs, click the link below corresponding to your deployment. If you're not sure, see How to determine your endpoint.
Authenticationβ
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.
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
,kr
, or au
, you're on one of those pods. The only exception is the US1 pod, which uses service.sumologic.com
.
The specific collection endpoint will vary per account. The general format is: endpoint[N].collection.[deploymentID].sumologic.com
.
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 sumologic.com:
*.sumologic.com
- By default, the Collector contacts
collectors.sumologic.com
before it is redirected to a deployment-specific endpoint such ascollectors.us2.sumologic.com
andendpoint[N].collection.[deploymentID].[sumologic.com]
.
- By default, the Collector contacts
- 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 Deployment | AWS Region Name | AWS Region |
---|---|---|
AU | Asia Pacific (Sydney) | ap-southeast-2 |
CA | Canada (Central) | ca-central-1 |
DE | EU (Frankfurt) | eu-central-1 |
EU | EU (Ireland) | eu-west-1 |
FED | US East (N. Virginia) | us-east-1 |
IN | Asia Pacific (Mumbai) | ap-south-1 |
JP | Asia Pacific (Tokyo) | ap-northeast-1 |
KR | Asia Pacific (Seoul) | ap-northeast-2 |
US1 | US East (N. Virginia) | us-east-1 |
US2 | US 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 | | if (region="ap-northeast-2", "KR", 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 Code | Error Code | Description |
---|---|---|
301 | moved | The requested resource SHOULD be accessed through returned URI in Location Header. See troubleshooting for details. |
401 | unauthorized | Credential could not be verified. |
403 | forbidden | This 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. |
404 | notfound | Requested resource could not be found. |
405 | method.unsupported | Unsupported method for URL. |
415 | contenttype.invalid | Invalid content type. |
429 | rate.limit.exceeded | The API request rate is higher than 4 request per second or in-flight API requests are higher than 10 request per second. |
500 | internal.error | Internal server error. |
503 | service.unavailable | Service 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.