diff --git a/blog/images/sandbox-env.png b/blog/images/sandbox-env.png
new file mode 100644
index 00000000..e30dca10
Binary files /dev/null and b/blog/images/sandbox-env.png differ
diff --git a/blog/sandbox-environments-reality-check.md b/blog/sandbox-environments-reality-check.md
new file mode 100644
index 00000000..d32017cf
--- /dev/null
+++ b/blog/sandbox-environments-reality-check.md
@@ -0,0 +1,421 @@
+---
+template: '../@theme/templates/BlogPost'
+title: The sandbox reality check
+description: Organizations want org-level sandbox environments for thousands of APIs. Here are the proven patterns that work at scale—and why they require platform building blocks, not just automation.
+seo:
+  title: Sandbox environments reality check | Redocly
+  description: Learn about proven org-level sandbox patterns that work at scale, what makes a real sandbox different from mock servers, and why platform building blocks matter more than automation.
+  image: ./images/sandbox-env.png
+author: adam-altman
+publishedDate: 2026-01-13
+categories:
+  - api-testing
+  - api-lifecycle
+  - developer-portal
+image: sandbox-env.png
+---
+
+# The sandbox reality check
+
+_Why organizations want org-level sandbox environments—and the proven patterns that actually work at scale._
+
+It's a common request: "Can we have a sandbox environment for all our APIs?"
+
+Especially in large organizations with thousands of APIs, teams frequently ask for an org-level sandbox pattern.
+They want developers to test integrations safely, certify workflows, and experiment without touching production.
+
+The good news: there are proven patterns that work at scale.
+
+The reality: they require platform building blocks and architectural thinking, not just automation.
+
+## The request
+
+The pattern is familiar.
+
+A payments team asks: "We need a sandbox for our 3,000+ APIs. Can the developer experience team build it?"
+
+A developer portal team asks: "Can we add a 'Try it' button that calls a sandbox directly from the documentation?"
+
+An integration team asks: "Why can't we just generate sandboxes from OpenAPI specs?"
+
+The request seems reasonable.
+After all, if you have API specifications, shouldn't you be able to create sandbox environments automatically?
+
+The answer is: **No, not really.**
+
+## Mock server vs. sandbox
+
+First, let's clarify what we're talking about.
+
+**A mock server:**
+- Generates responses based on the OpenAPI specification
+- Can be stateless or stateful (a "glorified mock server")
+- Relatively easy to build and maintain
+- Can be misleading because it doesn't reflect real system behavior
+
+**A sandbox:**
+- A real running system with realistic, stateful business logic
+- Same APIs as production, but different credentials and behavior changes
+- Environment-specific logic (fake payments, mocked rails, fake background checks)
+- Persistent, stateful behavior (create data, query it later, reset when needed)
+- Well-defined test inputs to trigger specific logical paths
+
+The difference is fundamental.
+
+A mock server answers: "Can I simulate a request/response?"
+
+A sandbox answers: "Can I simulate a use case?"
+
+## What makes a "real" sandbox
+
+A proper sandbox environment requires several critical components:
+
+**Separate environment with realistic behavior:**
+- Same authentication patterns (OAuth2, mTLS) but different keys/certificates than production
+- Environment-specific business logic (e.g., fake payment processing, mocked third-party services)
+- Realistic error handling and edge cases
+
+**Persistent, stateful behavior:**
+- You can create data (transactions, customers, orders) and query it later
+- State persists across requests until explicitly reset
+- Support for "wipe my sandbox data" functionality for developers
+
+**Well-defined test scenarios:**
+- Specific test inputs that trigger known logical paths
+- Test cards for "approved", "declined", "challenge", "timeout" scenarios
+- Country variants, currency variants, business rule variants
+- Each domain team must define and implement these scenarios
+
+**Instrumentation and analytics:**
+- Ability to observe sandbox usage (for sales, engagement, monitoring)
+- Tracking which APIs are being tested, by whom, and how often
+- Insights into integration patterns and developer behavior
+
+**Stripe as the gold standard:**
+- Stripe has one of the best sandbox implementations in the industry
+- Separate environment with rich special logic (e.g., configurable date/time)
+- Likely represents a multi-million dollar investment for that level of capability
+- Even Stripe doesn't have a "Try It" button calling sandbox directly from browser-based docs
+
+This isn't a simple problem.
+
+## The ownership problem
+
+Here's where it gets complicated.
+
+**Today's reality:**
+- Individual API/product teams are responsible for their own sandbox environments
+- Developer experience teams cannot own or build universal sandboxes
+- Any proper sandbox must be designed and implemented by API owners/business domains
+
+**Why ownership matters:**
+- Sandboxes require deep knowledge of business logic and dependencies
+- They need control over backend systems and test data
+- They require ongoing maintenance and scenario definition
+- They need domain expertise to define realistic test cases
+
+**What developer experience teams can do:**
+- Integrate with existing sandboxes (per API/team) into "Try it" where security/auth allow
+- Support patterns (e.g., proxying, "Try it" wiring) as a secondary layer
+- Provide documentation and discovery for sandbox environments
+- Help teams understand what's needed to build proper sandboxes
+
+**What developer experience teams cannot do:**
+- Stand up real sandboxes for product teams
+- Derive sandbox behavior from OpenAPI specs alone
+- Own the business logic and test scenarios
+- Make risk decisions about relaxing security requirements
+
+The developer experience team can facilitate, but they can't own.
+
+## The authentication challenge
+
+One of the biggest challenges is authentication.
+
+**mTLS and cert-based auth:**
+- Not web-friendly by design
+- To enable "Try it" from the developer portal, you'd need a backend proxy that:
+  - Holds or accesses user certs/keys securely
+  - Signs requests on behalf of the user
+- Raises security concerns and complexity (storing/uploading keys, scoping per user, etc.)
+
+**For sandbox environments:**
+- Some teams ask whether requirements can be relaxed because it's "fake money"
+- That's a business/risk decision, not a developer experience decision
+- Even sandboxes need proper security boundaries
+
+**Browser-based "Try it" limitations:**
+- Web auth constraints (mTLS not directly doable in browser; needs proxies)
+- You can't realistically do full integration flows in the developer portal UI
+- For payment-style APIs, sandbox's primary purpose is safe integration and certification, not clicking a single button on a web page
+
+True integration means system-to-system calls from the consumer's environment to the sandbox.
+
+Browser-based testing is useful, but it's not the same as real integration testing.
+
+## Why you can't derive sandboxes from specs
+
+Here's a critical point: **You cannot derive a real sandbox only from the OpenAPI spec.**
+
+**What OpenAPI specs provide:**
+- API contract (endpoints, parameters, responses)
+- Schema definitions
+- Authentication requirements
+- Basic documentation
+
+**What OpenAPI specs don't provide:**
+- Full business logic and dependencies
+- Test scenarios and edge cases
+- State management requirements
+- Integration patterns with other systems
+- Domain-specific behavior (e.g., payment processing rules)
+
+**What you need for a real sandbox:**
+- Knowledge of full business logic and dependencies
+- Control over backend systems and test data
+- Ability to configure environment-specific behavior
+- Domain expertise to define realistic test scenarios
+
+It's a spectrum, and each point on that spectrum requires different levels of investment and ownership.
+
+## The org-level pattern question
+
+Here's the reality: **There are common org-level sandbox patterns that work at scale, but they require separating "a place to safely test" from "a million snowflake sandboxes."**
+
+The main trick is architectural patterns and platform support, not magic automation.
+
+When you're dealing with hundreds or thousands of services, you can't have each team build completely independent sandboxes.
+Instead, successful organizations use one of several proven patterns.
+
+## Common org-level sandbox patterns
+
+Here are the patterns that actually work at scale:
+
+### 1. Shared sandbox environment + tenant isolation (most common)
+
+**The pattern:**
+- One (or a small number) of shared sandbox clusters
+- Isolation is done at the tenant/account level (and sometimes namespace + quotas)
+
+**Pros:**
+- Cheapest to run
+- Easiest to govern
+- Consistent developer experience
+
+**Cons:**
+- Noisy neighbors
+- Harder to support "I need prod-like data" requests
+
+**When it works well:**
+- Strong rate limits/quotas
+- Per-tenant data partitions
+- Good observability
+- Clear "no PII" policy
+
+### 2. "Sandbox is just prod, but limited side effects"
+
+**The pattern:**
+- Prod codepaths, but no side effects (or side effects go to a sink)
+- Hard caps on spend / rate / blast radius
+
+**Typical techniques:**
+- "Dry-run" headers (`Prefer: return=minimal`, `X-Dry-Run: true`)
+- Idempotency + policy gates that refuse "dangerous" actions unless allowlisted
+- Writes go to a shadow datastore or are auto-expired
+
+**Pros:**
+- Closest behavior to prod
+
+**Cons:**
+- Hard to guarantee no leakage
+- Requires discipline across services
+
+### 3. Virtualized / mocked sandbox at the edge ("API facade sandbox")
+
+**The pattern:**
+- A single sandbox gateway
+- Backed by mocks, simulators, contract tests, and recorded fixtures
+- Optionally selective pass-through to a few real sandboxed backends
+
+**Pros:**
+- Scales across thousands of services without running them all
+
+**Cons:**
+- Can drift from reality unless you invest in contract testing + refresh pipelines
+
+**When it works well:**
+- Partner/public APIs where "predictable" beats "perfectly prod-like"
+
+### 4. Per-team or per-domain sandboxes (federated)
+
+**The pattern:**
+- Each domain owns its own sandbox
+- Org provides a standard blueprint:
+  - DNS conventions
+  - Auth model
+  - Request tracing
+  - Quotas/rate limits
+  - Data policies
+
+**Pros:**
+- Autonomy
+- Easier for teams to maintain accuracy
+
+**Cons:**
+- Inconsistent experience unless the platform team enforces standards
+
+### 5. Ephemeral preview environments (PR-based) for integration testing
+
+**The pattern:**
+- "Sandbox" is created per PR or per branch, lives for hours/days
+
+**Pros:**
+- Very safe
+- Very realistic for change validation
+
+**Cons:**
+- Not stable enough for external consumers
+- Expensive if abused
+
+**When it works well:**
+- Internal dev velocity
+- Less good as a stable partner sandbox
+
+### 6. Synthetic-data sandboxes (data is the product)
+
+**The pattern:**
+- Environment might be stable, but the key is:
+  - Seeded synthetic datasets
+  - Deterministic fixtures per tenant
+  - Resettable state ("factory reset" endpoints)
+
+**Pros:**
+- Test repeatability
+- Easier support
+
+**Cons:**
+- Building good synthetic data is work
+
+## Cross-cutting building blocks
+
+Regardless of which pattern you choose, successful org-level sandboxes almost always include:
+
+**Separate auth + credentials:**
+- Different issuer, audience, scopes for sandbox
+- Distinct base domains (`api.sandbox.company.com`) + strict routing controls
+
+**Central gateway + policy engine:**
+- Rate limits, payload size, PII rules, method restrictions
+- Global quotas per tenant and per service
+- "Fair use" policies
+
+**Contract-first approach:**
+- OpenAPI + linting + compatibility checks to prevent sandbox drift
+- Contract testing + refresh pipelines
+
+**Write controls:**
+- Dry-run, allowlists, TTL'd resources, "side-effect sinks"
+- Traffic shaping and quotas
+
+**Observability as a product:**
+- Request IDs, traces
+- "Why was I blocked" errors
+- Usage analytics and insights
+
+These building blocks are what make org-level patterns work—they're the platform layer that enables teams to build sandboxes consistently.
+
+## Choose the right pattern
+
+The pattern you choose depends on your use case:
+
+**If you need partner onboarding at scale:**
+→ Edge-virtualized sandbox (facade) + contracts
+
+**If you need realistic behavior for internal integration:**
+→ Shared sandbox + tenant isolation + synthetic data
+
+**If you need prod parity:**
+→ Restricted-prod pattern, but invest heavily in guardrails
+
+The key is matching the pattern to your actual needs, not trying to build the perfect sandbox for every scenario.
+
+## Practical guidance
+
+So what should organizations do?
+
+**For platform/developer experience teams:**
+- Don't try to build universal sandboxes for every API
+- Do provide the building blocks (auth, gateway, policy engine, observability)
+- Do establish patterns and conventions (DNS, auth model, tracing, quotas)
+- Do integrate with existing sandboxes into "Try it" where security/auth allow
+- Do support patterns (e.g., proxying, "Try it" wiring) as a secondary layer
+- Do provide documentation and discovery for sandbox environments
+- Do enforce standards across federated sandboxes
+
+**For product/API teams:**
+- Choose the right pattern for your use case (don't default to "build our own")
+- Define whether you truly want a full sandbox or just richer, possibly stateful mocks
+- Design, fund, and implement sandbox behavior and scenarios
+- Own the business logic and test scenarios
+- Provide sandbox environments that follow org-level patterns and conventions
+
+**For organizations:**
+- Recognize that sandboxes are a platform investment, not just a developer portal feature
+- Provide the building blocks and patterns that enable consistent sandboxes
+- Support teams in choosing and implementing the right pattern
+- Don't expect developer experience teams to own business logic, but do expect them to provide platform support
+
+**The decision framework:**
+
+1. **What's your use case?**
+   - External partner onboarding → Edge-virtualized sandbox (facade) + contracts
+   - Internal integration testing → Shared sandbox + tenant isolation + synthetic data
+   - Prod parity required → Restricted-prod pattern with heavy guardrails
+
+2. **What do you actually need?**
+   - Full sandbox, stateful mock, or simple mock server?
+   - Realistic behavior or predictable behavior?
+
+3. **Who owns what?**
+   - Platform teams own building blocks (auth, gateway, policy, observability)
+   - Product teams own business logic and test scenarios
+   - Developer experience teams facilitate integration and discovery
+
+4. **What's the investment?**
+   - Platform building blocks require significant investment
+   - Individual sandboxes require domain expertise and ongoing maintenance
+   - Real sandboxes require significant investment (think Stripe's multi-million dollar capability)
+
+5. **What's the value?**
+   - Is the value worth the investment for your use case?
+   - Can you start with a simpler pattern and evolve?
+
+## The takeaway
+
+Sandbox environments are valuable, but they're not simple.
+
+**The reality:**
+- You can't derive a real sandbox from an OpenAPI spec alone
+- Sandboxes require business logic, domain expertise, and ongoing maintenance
+- There ARE proven org-level patterns that work at scale
+- But they require platform building blocks and architectural thinking, not just automation
+
+**The path forward:**
+- Organizations provide platform building blocks (auth, gateway, policy, observability)
+- Organizations establish patterns and conventions (shared, federated, virtualized, etc.)
+- Product teams choose the right pattern and own business logic
+- Platform/developer experience teams provide the infrastructure and facilitate integration
+- Everyone recognizes that sandboxes are a platform investment, not just a developer portal feature
+
+The request is reasonable, but the solution requires clarity about:
+- What pattern fits your use case
+- What building blocks you need
+- Who owns what (platform vs. product vs. developer experience)
+
+Because when it comes to sandboxes, architecture matters more than automation.
+
+The patterns exist.
+The building blocks are known.
+The question is: Are you building the platform that makes them possible?
+
+And that's the reality check.