Integrations
How SDKs extend functionality through modular integrations — interface, lifecycle, configuration, and default integration guidelines.
This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in RFC 2119 to indicate requirement levels.
Statusstable
Integrations extend SDK functionality in a modular way. The Client MUST own integration instances and call their lifecycle methods.
Users configure integrations via the integrations option in Sentry.init().
Related specs:
- Client — client lifecycle and event pipeline
- HTTP Client Integration — HTTP client instrumentation guidelines
- GraphQL Integration — GraphQL client instrumentation guidelines
- Feature Flags Integration — feature flag tracking guidelines
- Modules Integration — loaded library and version reporting
Stablespecified since 1.0.0
The recommended integration interface (language-specific variations apply):
| Method | When Called | Purpose |
|---|---|---|
setupOnce() | Once globally, for the first Client | Global side effects (monkey-patching, global handlers). |
setup(client) | Per Client | Client-specific setup. Preferred over setupOnce for most work. |
afterAllSetup(client) | After all integrations' setup | Work that depends on other integrations being set up. |
preprocessEvent(event, hint, client) | Before event processors | Modify the event before other processing. |
processEvent(event, hint, client) | During event pipeline | Process the event. Return null to discard. |
Stablespecified since 1.0.0
Users configure integrations via the integrations option:
Copied
Sentry.init({ integrations: [Sentry.browserTracingIntegration()], }); Sentry.init() MUST enable a set of default integrations that define baseline functionality. SDKs MUST expose a way to disable default integrations individually or entirely.
Stablespecified since 1.0.0
New default integrations SHOULD:
- Be lightweight — not add significant overhead
- Be well-tested across all supported environments
- Not create a high volume of new data (spans, transactions) without user opt-in
Integrations that create high data volume or have potential compatibility issues SHOULD be opt-in and only made default in a major version.
| Version | Date | Summary |
|---|---|---|
1.0.0 | 2025-02-24 | Initial spec, extracted from client spec v2.1.0 |
Was this helpful?
Help improve this content
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").
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").