Event Payloads
Events are the fundamental data that clients, often through the use of an SDK, send to the Sentry server.
Events are packed into envelopes and are sent to the /api/{PROJECT_ID}/envelope/
API endpoint.
Sending event payloads to the /api/{PROJECT_ID}/store/
API endpoint is deprecated.
Note on backwards compatibility
We strive to document the canonical format of an event and its additional interfaces. However, for backwards compatibility the server also understands events that are not in the canonical format described throughout the documentation.
Existing SDKs may be using a historical format that is not recommended for new code.
Found a problem?
If documentation is lacking or outdated, please let us know by opening an issue.
SDK developers might benefit from consulting the documentation and source code defining the protocol as understood by the server.
Attributes are simple data that Sentry understands to provide the most basic information about events. These are things like the unique ID of an event or the time when it occurred.
The following attributes are required for all events.
event_id
Required. Hexadecimal string representing a uuid4 value. The length is exactly 32 characters. Dashes are not allowed. Has to be lowercase.
{
"event_id": "fc6d8c0c43fc4630ad850ee518f1b9d0"
}
timestamp
- Indicates when the event was created in the Sentry SDK. The format is either astring as defined in RFC 3339 or anumeric (integer or float) value representing the number of seconds that haveelapsed since the Unix epoch.
{
"timestamp": "2011-05-02T17:41:36Z"
}
or:
{
"timestamp": 1304358096.0
}
platform
- A string representing the platform the SDK is submitting from. This will beused by the Sentry interface to customize various components in the interface.
{
"platform": "python"
}
Acceptable values are:
as3
c
cfml
cocoa
csharp
elixir
haskell
go
groovy
java
javascript
native
node
objc
other
perl
php
python
ruby
Additionally, there are several optional values which Sentry recognizes and are highly encouraged:
level
- The record severity.
Defaults to error
.
The value needs to be one on the supported level string values.
{
"level": "warning"
}
Acceptable values are:
fatal
error
warning
info
debug
logger
- The name of the logger which created the record.
{
"logger": "my.logger.name"
}
transaction
- The name of the transaction which caused this exception.
For example, in a web app, this might be the route name.
{
"transaction": "/users/<username>/"
}
server_name
- Identifies the host from which the event was recorded.
{
"server_name": "foo.example.com"
}
release
- The release version of the application.
Release versions must be unique across all projects in your organization. This value can be the git SHA for the given project, or a product identifier with a semantic version (suggested format my-project-name@1.0.0
).
{
"release": "my-project-name@1.0.0"
}
dist
- The distribution of the application.
Distributions are used to disambiguate build or deployment variants of the same release of an application. For example, the dist can be the build number of an Xcode build or the version code of an Android build.
{
"release": "721e41770371db95eee98ca2707686226b993eda",
"dist": "14G60"
}
tags
Optional. A map or list of tags for this event. Each tag must be less than 200 characters.
{
"tags": {
"ios_version": "4.0",
"context": "production"
}
}
environment
- The environment name, such as
production
orstaging
. The default value should beproduction
.
{
"environment": "production"
}
modules
- A list of relevant modules and their versions.
{
"modules": {
"my.module.name": "1.0"
}
}
extra
- An arbitrary mapping of additional metadata to store with the event.
{
"extra": {
"my_key": 1,
"some_other_value": "foo bar"
}
}
fingerprint
- A list of strings used to dictate the deduplication of this event.
{
"fingerprint": ["myrpc", "POST", "/foo.bar"]
}
For information about overriding grouping see Customize Grouping with Fingerprints.
errors
- A list of errors in capturing or handling this event. This provides meta dataabout event capturing and processing itself, not about the error ortransaction that the event represents.
This list is primarily populated by Sentry when receiving and processing the event. SDKs are only encouraged to add entries here if there are severe conditions that Sentry cannot detect by inspecting the remaining payload.
Errors must contain a required type
field, which can be one of the types declared in the Sentry EventError model. If there is no applicable type variant, consider opening an issue to suggest the addition.
Apart from types, any attribute is valid. There are conventions for the semantics of common error attributes, if they are included:
name
: A string declaring the path to the payload field that causes or exhibits the error. For examplemodules[0].name
.value
: The original value of a field that causes or exhibits the error.
{
"errors": [
{
"type": "unknown_error",
"path": "/var/logs/errors.log.1",
"details": "Failed to read attachment"
}
]
}
Event ingestion imposes limits on the size of events. These limits are subject to future change and defined currently as:
- 1MB decompressed (and
200KB
compressed) for events of typeerror
- 1MB decompressed (and
200KB
compressed) for events of typetransaction
Sessions, client reports, replays, check-ins, and profiles are not events and have different size limits. See Envelope Size Limits.
All values in the event payload that are not basic attributes are data interfaces. The key is the canonical interface short name, and the value is the data expected by the interface (usually a dictionary).
For the most part, interfaces are an evolving part of Sentry. Like with attributes, SDKs are expected to assume that more interfaces will be added at any point in the future.
The core data interfaces are:
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").