SDKs should allow bypassing API key format validation for custom/self-hosted endpoints

[jimyag]

Summary

After #1356, both the JS and Python SDKs validate API keys client-side and only accept keys matching the e2b_<hex> format.

This is helpful for E2B Cloud, but it breaks compatibility with custom or self-hosted endpoints that expose an E2B-compatible API while using a different credential format.

Context

We are using a custom endpoint via domain / apiUrl.

That backend accepts a different API key format (for example sk-...), and this used to work with older SDK versions because the request was sent to the backend directly.

With the newer SDK behavior introduced in #1356, the SDK rejects the key locally before making any HTTP request.

This affects both:

• the JS SDK
• the Python SDK

Problem

The SDK currently assumes that any backend reached through domain / apiUrl must also use the official E2B Cloud API key format.

That assumption is valid for E2B Cloud, but not necessarily for:

• self-hosted deployments
• private compatible backends
• custom gateways/proxies that intentionally use a different credential scheme

As a result, valid credentials for custom deployments are rejected before the server can evaluate them.

Possible fixes

A few implementation options would solve this cleanly:

1. Automatically skip client-side API key format validation when a custom domain or apiUrl is provided.

   • This keeps the current behavior for E2B Cloud.
   • It avoids hardcoding E2B Cloud credential assumptions for self-hosted or compatible backends.

2. Add an explicit SDK option to skip validation.

   • JS example: skipApiKeyValidation: true
   • Python example: skip_api_key_validation=True

3. Add an environment-variable-based escape hatch.

   • Example: E2B_SKIP_API_KEY_VALIDATION=1

Preferred direction

My preference would be one of these:

• automatically skip validation for custom endpoints, or
• add an explicit opt-out parameter for self-hosted / compatible deployments

Either approach would preserve the better UX for E2B Cloud users while restoring compatibility for custom deployments.

Additional note

This request is not about weakening validation for E2B Cloud.

It is specifically about avoiding hardcoded credential-format assumptions when the SDK is pointed at a non-default backend.

Offer to help

If this direction is acceptable, I’d be happy to help implement it and open a PR.

If you prefer, I can prepare a PR for:

• skipping validation when domain / apiUrl is customized, or
• adding an explicit opt-out flag in both JS and Python SDKs.

[linear-code]

ENG-4271

[mishushakov]

PR is waiting for merge here: #1360

I'll let you know once that happens!

[jimyag]

PR is waiting for merge here: #1360

I'll let you know once that happens!

Thanks for working on this. I agree that a configurable prefix is useful, and it should cover deployments whose keys follow the same shape as E2B keys, for example sk-<lowercase-hex>.

My concern is that this still assumes the token body is lowercase hex. For custom/self-hosted endpoints, the credential format may be backend-defined and could be an opaque token, mixed-case string, JWT, or a provider-style key like sk-... with non-hex characters.

So I think apiKeyPrefix is a good improvement, but it may not be enough as the compatibility escape hatch for non-official endpoints.

Would you consider keeping strict client-side validation for the default E2B Cloud endpoint, but skipping API key format validation when a custom domain / apiUrl is configured? That would preserve the current UX improvement for E2B Cloud users while letting custom backends validate their own credentials server-side.