API Security Enhancements
What's Changing and What You Need to Do
Enforcement Date: November 13, 2026
To align with industry-standard security practices, we are rolling out a set of security enhancements across our API products. These changes require action from customers who have not yet updated their integrations. This page outlines what's changing, why, and what you need to do before the enforcement date.
Summary of Changes
| # | Change | Status |
|---|---|---|
| 1 | HTTPS-only enforcement (HTTP requests rejected) | ⏳ Effective November 13, 2026 |
| 2 | API key required in request header (no longer accepted in URL) | ⏳ Effective November 13, 2026 |
| 3 | Removal of XSL stylesheet support | ⏳ Effective November 13, 2026 |
| 4 | Deprecated TLS cipher suites no longer accepted | ⏳ Effective November 13, 2026 |
Note: This deadline was extended from an original date of July 31, 2026 to give customers additional time to complete these updates. November 13, 2026 is the final enforcement date.
1. HTTPS Enforcement
What's changing: Starting November 13, 2026, we will no longer accept API requests made over plain HTTP. All requests must use HTTPS.
What you need to do: If your integration currently sends requests to http:// endpoints, update your configuration to use https:// instead. Most integrations already redirect automatically, but any client that hard-codes an http:// URL or bypasses redirects will stop working after the enforcement date.
How to check: Review your integration's base URL configuration and confirm all outbound requests use https://.
2. API Key in Request Header (Not URL)
What's changing: API keys will no longer be accepted as a query parameter in the request URL (e.g., ?api_key=... or ?x-api-key=...). All requests must pass the API key in the request header instead.
What you need to do: Update your integration to send the API key via request header rather than embedding it in the URL.
Why this matters: Passing credentials in the URL is a security risk — URLs are frequently logged by proxies, browsers, and analytics tools, which can expose your API key. Header-based authentication avoids this exposure.
How to check: Search your integration code for how the API key is attached to requests. If it appears anywhere in the URL string, it needs to move to a header.
This capability has been available since April 2024 — if your integration was built or updated after that date, it may already support header-based authentication.
3. Removal of XSL Stylesheet Support
What's changing: XSL stylesheet support will be removed as part of this update.
What you need to do: If your integration relies on XSL stylesheets for rendering or transforming API responses, you'll need to move that logic to your own application layer before the enforcement date.
Note: XSL stylesheets will stop functioning as soon as API key header enforcement takes effect, since both changes land at the same time.
4. Updated List of Acceptable TLS Ciphers
What's changing: A set of outdated TLS cipher suites will no longer be supported. Connections using these ciphers will be rejected after November 13, 2026.
What you need to do: Confirm your integration's TLS configuration uses a currently-supported cipher suite. Most modern HTTP clients and libraries negotiate ciphers automatically and won't require any changes — this primarily affects older or custom TLS configurations.
How to check: If you're unsure which cipher suite your integration uses, check with whoever manages your TLS/SSL configuration. We will also reach out directly to impacted customers since this configuration can be harder to catch.
For the full list of supported ciphers, see our API Security Policies.
Action Checklist
Use this checklist to confirm your integration is ready:
- All requests use
https://, nothttp:// - API key is passed via request header, not in the URL
- No dependency on XSL stylesheets for API response handling
- TLS configuration does not rely on deprecated cipher suites
If you've already completed these steps, no further action is needed.
Updated 4 days ago