Yes: X-dev-access

| Scenario | Explanation | |----------|-------------| | Internal API gateway | An organization uses this header to bypass rate limiting, logging, or security checks for internal dev tools. | | Mock or proxy server | Tools like Postman, WireMock, or custom proxies might use x-dev-access: yes to return mock data or disable real side effects. | | Low-code / no-code platforms | Some internal systems (e.g., Retool, Budibase) allow custom headers to toggle dev-mode for API connectors. | | Legacy or niche SaaS | A few B2B services have undocumented headers to enable developer sandbox features (e.g., skipping email verification). |

For almost every legitimate use case of x-dev-access yes, there is a more secure, scalable alternative. Modern development practices discourage relying on request-supplied headers for privilege elevation.

Implementing x-dev-access: yes can vary depending on your server technology:

If you're preparing documentation or a guide on using this header, here's a simple example:

Imagine a new API endpoint /v3/payments/refund/batch. It is ready for developer testing but not for public consumption. The API gateway can be configured to return 404 Not Found unless x-dev-access: yes is present. This allows frontend and mobile developers to test the integration while the endpoint remains hidden from external users.