Set default endpoints based on API key

[twometresteve]

Goal

Set default endpoints based on API key. If no endpoint is configured, payloads should be sent to *.insighthub.smartbear.com if the API key starts with 00000.

Design

The logic that defaults the endpoints based on the API key depends on configure not being called before it is called with the API key. Although our integration guide directs people to use bugsnag.configure(for a single Bugsnag client), it is also possible to use multiple Client. In singleton mode (using legacy.py) Client is instantiated and calls configure without any arguments - breaking that dependency.

As a solution to that, avoiding breaking existing uses of Client, I've added a configure parameter to the Client constructor, defaulting to true but allowing the "legacy" mode to stop it being called (with no actual arguments).

Testing

Unit tests added and the existing tests also caught an issue in development. I've also run some manual tests locally with an example app, verifying that the requested host is as expected for different API keys. That exercise highlighted the issue with single/multiple clients.

[Copilot]

Pull Request Overview

This PR updates the default endpoint logic to choose between Bugsnag and Insighthub endpoints based on the API key and adjusts the legacy client behavior accordingly. Key changes include:

• Updating tests to reflect the new default session endpoint behavior.
• Adding new hub endpoint constants and updating session delivery logic.
• Modifying the Client constructor in legacy mode to avoid automatic configuration.

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tests/test_configuration.py	Updated tests to validate endpoint defaults based on API key.
bugsnag/legacy.py	Adjusted Client instantiation to prevent legacy auto-configuration.
bugsnag/delivery.py	Added hub-specific endpoints and updated session delivery logic.
bugsnag/configuration.py	Introduced _initialize_endpoints to choose defaults per API key.
bugsnag/client.py	Added configure parameter to the Client constructor.
CHANGELOG.md	Updated changelog to reflect these changes.

Comments suppressed due to low confidence (2)

tests/test_configuration.py:86

• The test 'test_session_tracking_defaults' now expects session_endpoint to be None. Consider adding a comment or renaming the test to clarify that the default session_endpoint is intentionally not set, in order to enforce explicit configuration.

        self.assertEqual(c.session_endpoint, None)

bugsnag/configuration.py:602

• [nitpick] Adding an inline comment here to explain that hub-specific endpoints are being set when the API key starts with the hub prefix would enhance readability for future maintainers.

            if _is_hub_api_key(api_key):

[Copilot]

[nitpick] Consider refactoring the compound condition in deliver_sessions for clarity. Splitting the check into separate conditional statements or adding inline comments explaining each branch would improve maintainability.

Suggested change

	if ((config.endpoint != DEFAULT_ENDPOINT and
	config.session_endpoint == DEFAULT_SESSIONS_ENDPOINT) or
	(config.endpoint != HUB_ENDPOINT and
	config.session_endpoint == HUB_SESSIONS_ENDPOINT)):
	# Check if the session endpoint is not properly configured
	is_default_endpoint_mismatch = (
	config.endpoint != DEFAULT_ENDPOINT and
	config.session_endpoint == DEFAULT_SESSIONS_ENDPOINT
	)
	is_hub_endpoint_mismatch = (
	config.endpoint != HUB_ENDPOINT and
	config.session_endpoint == HUB_SESSIONS_ENDPOINT
	)
	if is_default_endpoint_mismatch or is_hub_endpoint_mismatch:

[tomlongridge]

As discussed IRL, the semi-internal new parameter seems the least intrusive or potential for breaking option. It's tempting to create a new client when bugsnag.configure is called, but it's potential that users might be relying on some side-effect of having the same client instance, so I'm happy to avoid that uncertainty with this approach.