API gateway migration
We're migrating our API gateway to a new architecture.
What's changing
This is an internal change and doesn't affect the API contract, except for the items below, where the new gateway applies stricter, RFC-compliant validation of incoming requests.
- Query parameters with unencoded special characters (for example accented letters) now return
400instead of200. Percent-encode all query parameter values. - Requests that set both Content-Length and Transfer-Encoding: chunked now return
400instead of200. Only one of these headers should be sent per request. - mTLS integrations only: an untrusted or expired client certificate now closes the connection at the TLS handshake instead of returning
403.
Rollout time
These changes are enforced at the gateway edge, ahead of API version routing, so they apply to all customers regardless of the Numeral-Api-Version header they're pinned to. This migration is treated as an exception to our standard API versioning, which doesn't cover infrastructure-layer changes. The usual 12-month version support and 90-day migration window don't apply here.
The new API gateway has been running on the sandbox environment for a few weeks with no issues found.
It will be rolled out in production on October 6, 2026, 10am CET. No downtime is expected.
Action requested
Please test your integration in the sandbox environment using the same request patterns you run in production, particularly:
- Query parameters that may include accented letters, spaces, or other special characters
- Requests that set both Content-Length and Transfer-Encoding headers
- Any reliance on error codes to catch malformed query parameters
- mTLS connections, if you use certificate-based authentication
This is the best way to catch encoding and validation issues before the change reaches production.
Questions
Reach out to [email protected] if you have questions or run into unexpected issues.