---
# === IDENTITY ===
id: business/erp-integration/oracle-erp-cloud-sandbox-limitations/2026
canonical_question: "What are Oracle ERP Cloud sandbox limitations for integration testing?"
aliases:
  - "Oracle Fusion Cloud sandbox restrictions for testing"
  - "Oracle ERP Cloud test environment limitations vs production"
  - "Oracle Cloud sandbox data refresh limitations"
  - "Oracle Fusion Cloud test pod vs production environment differences"
entity_type: erp_integration
domain: business > erp-integration > oracle-erp-cloud-sandbox-limitations
region: global
jurisdiction: global
temporal_scope: 2025-2026

# === SYSTEM PROFILE ===
systems:
  - name: "Oracle Fusion Cloud ERP"
    vendor: "Oracle"
    version: "25A-25D"
    edition: "Enterprise"
    deployment: cloud
    api_surface: "REST, SOAP, FBDI"

# === VERIFICATION ===
last_verified: 2026-03-09
confidence: 0.82
version: 1.0
first_published: 2026-03-09

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "25C — environment refresh process updated"
  next_review: 2026-09-05
  change_sensitivity: medium

# === CONSTRAINTS ===
constraints:
  - "Maximum 20 open sandboxes per environment by default (profile option configurable but impacts performance)"
  - "Sandbox changes are invisible to other users, integrations, and batch processes until published"
  - "Environment refresh cannot target production — production can never be refreshed/overwritten"
  - "Source and target environments must be at the same Fusion Applications version and patch level for refresh"
  - "Standard subscription includes 1 production + 1 test environment — additional test environments (ATEs) cost extra"
  - "Test pod API rate limits may differ from production — performance tests may not be representative"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs to understand what can be customized, not how to test it"
    use_instead: "business/erp-integration/oracle-erp-cloud-customization-boundaries/2026"
  - condition: "User needs regression testing strategy for quarterly updates"
    use_instead: "business/erp-integration/oracle-erp-cloud-upgrade-impact-integrations/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: environment_type
    question: "Which environment type are you testing in?"
    type: choice
    options:
      - "Sandbox (within production or test)"
      - "Test pod (non-production environment)"
      - "Development environment (ATE)"
      - "Production"
  - key: testing_type
    question: "What type of testing do you need?"
    type: choice
    options:
      - "Integration testing (API connections)"
      - "Regression testing (post-update)"
      - "Performance/load testing"
      - "Configuration testing (flexfields, workflows)"
      - "Data migration testing"
  - key: data_requirements
    question: "What data do you need in the test environment?"
    type: choice
    options:
      - "Production data clone"
      - "Subset of production data"
      - "Synthetic test data"
      - "No specific data requirements"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/oracle-erp-cloud-sandbox-limitations/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-09)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to:
    - id: "business/erp-integration/oracle-erp-cloud-customization-boundaries/2026"
      label: "Customization boundaries that affect what can be tested in sandboxes"
    - id: "business/erp-integration/oracle-erp-cloud-upgrade-impact-integrations/2026"
      label: "Quarterly update testing using test pod"
  solves: []
  alternative_to: []
  often_confused_with:
    - id: "business/erp-integration/oracle-erp-cloud-customization-boundaries/2026"
      label: "Customization boundaries (what to build) vs sandbox (where to test)"

# === SOURCES ===
sources:
  - id: src1
    title: "Best Practices for Configuring and Extending Fusion Applications Cloud"
    author: Oracle A-Team
    url: https://www.ateam-oracle.com/post/best-practices-for-configuring-and-extending-fusion-applications-cloud
    type: technical_blog
    published: 2024-06-10
    reliability: high
  - id: src2
    title: "Refreshing an Environment"
    author: Oracle
    url: https://docs.oracle.com/en-us/iaas/Content/fusion-applications/refresh-environment.htm
    type: official_docs
    published: 2025-06-01
    reliability: authoritative
  - id: src3
    title: "Overview of Fusion Applications Environment Management"
    author: Oracle
    url: https://docs.oracle.com/en-us/iaas/Content/fusion-applications/overview.htm
    type: official_docs
    published: 2025-06-01
    reliability: authoritative
  - id: src4
    title: "Oracle Fusion Applications Cloud Instance Strategy and Global Single Instance Guidelines"
    author: Oracle A-Team
    url: https://www.ateam-oracle.com/oracle-fusion-applications-cloud-instance-strategy-and-global-single-instance-guidelines
    type: technical_blog
    published: 2024-08-20
    reliability: high
  - id: src5
    title: "Testing Strategy for Oracle Cloud ERP Implementation"
    author: Opkey
    url: https://www.opkey.com/blog/testing-strategy-for-oracle-cloud-erp-implementation-a-step-by-step-guide
    type: community_resource
    published: 2025-01-15
    reliability: moderate_high
  - id: src6
    title: "What is Sandbox in Oracle Fusion"
    author: Oracle Community
    url: https://rpforacle.blogspot.com/2018/02/what-is-sandbox-in-oracle-fusion.html
    type: community_resource
    published: 2024-02-01
    reliability: moderate
---

# Oracle ERP Cloud Sandbox Limitations for Integration Testing

## TL;DR

- **Bottom line**: Oracle Fusion Cloud ERP has three testing levels — sandboxes (configuration isolation within an environment), test pods (separate non-production environments), and ATEs (Additional Test Environments) — each with distinct limitations for integration testing. Sandboxes are the most restrictive: changes are invisible to integrations until published. [src1, src3]
- **Key limit**: Maximum 20 open sandboxes per environment (configurable but performance-impacting). Sandboxes only isolate configuration changes (flexfields, Page Composer, App Composer) — they do not provide separate data or API endpoints. [src1]
- **Watch out for**: Sandbox changes are completely invisible to REST APIs, FBDI imports, and batch processes until published to mainline. You cannot test integrations against sandbox-only configurations. [src1]
- **Best for**: Teams planning testing strategies for Oracle Cloud ERP customizations and integrations.
- **Authentication**: Same credentials work across sandbox and mainline within the same environment. Test pod requires separate credentials.

## System Profile

Oracle Fusion Cloud ERP provides multiple testing mechanisms, each designed for different testing needs. Understanding the limitations of each is critical for effective integration testing. This card covers the three primary testing contexts: (1) Sandboxes within an environment, (2) Test pods (non-production environments), and (3) Additional Test Environments (ATEs). The standard Oracle Cloud ERP subscription includes 1 production environment and 1 test environment. Additional test environments require separate procurement. [src3, src4]

| Property | Value |
|---|---|
| **Vendor** | Oracle |
| **System** | Oracle Fusion Cloud ERP (25A-25D) |
| **API Surface** | REST, SOAP, FBDI |
| **Environments Included** | 1 Production + 1 Test (standard) |
| **Additional Test Environments** | Purchasable (ATEs) |
| **Sandbox Limit** | 20 per environment (configurable) |
| **Deployment** | Cloud |
| **Environment Management** | [Oracle Fusion Environment Management](https://docs.oracle.com/en-us/iaas/Content/fusion-applications/overview.htm) |
| **Status** | GA |

## API Surfaces & Capabilities

| Testing Level | Data Isolation | API Isolation | Config Isolation | Integration Testable? | Cost |
|---|---|---|---|---|---|
| Sandbox | None — shares production data | None — same endpoints | Yes — isolated config changes | No — changes invisible to APIs | Included |
| Test Pod (Non-Prod) | Separate data (refreshable from prod) | Separate URL/endpoints | Separate from production | Yes — fully testable | Included (1 instance) |
| ATE (Additional Test) | Separate data (refreshable) | Separate URL/endpoints | Fully independent | Yes — fully testable | Extra cost |
| Production | N/A | Production endpoints | Mainline (published) | N/A — this is production | Included |

[src3, src4]

## Rate Limits & Quotas

### Environment Allocation

| Resource | Standard Subscription | Notes |
|---|---|---|
| Production environments | 1 | Cannot be refreshed/overwritten |
| Test environments | 1 | Can be refreshed from production |
| Additional Test Environments | Purchasable | Separate procurement, separate cost |
| Sandboxes per environment | 20 (default) | ORACLE.ADF.SHARE.SANDBOX.MAXIMUMSANDBOXCOUNT |
| Users per sandbox | 1 (recommended) | Multiple possible but merge conflict risk |

[src3, src4]

### Sandbox Limitations

| Capability | Sandbox | Test Pod | ATE |
|---|---|---|---|
| Flexfield configuration | Yes (isolated) | Yes (independent) | Yes (independent) |
| Page Composer changes | Yes (isolated) | Yes (independent) | Yes (independent) |
| Application Composer | Yes (isolated) | Yes (independent) | Yes (independent) |
| REST API testing | No (invisible) | Yes (separate URL) | Yes (separate URL) |
| FBDI import testing | No (invisible) | Yes (separate instance) | Yes (separate instance) |
| Business Event testing | No (invisible) | Yes (separate instance) | Yes (separate instance) |
| ESS job testing | No (invisible) | Yes (separate instance) | Yes (separate instance) |
| Load/performance testing | No | Limited (lower limits) | Limited (lower limits) |
| Production data clone | N/A (same data) | Yes (via refresh) | Yes (via refresh) |
| Independent update schedule | No (same environment) | Yes (updated ~2 weeks before prod) | Yes (configurable) |

[src1, src3]

### Environment Refresh Constraints

| Constraint | Details | Impact |
|---|---|---|
| Production cannot be refreshed | Production is never overwritten | One-way: prod → test only |
| Version match required | Source and target must be at same Fusion version and patch level | Cannot refresh if versions differ |
| Data after backup | Some data may not match if activity occurred on source after backup | Timing matters for data consistency |
| Target unavailable during refresh | The target environment is down during refresh | Plan refresh during maintenance window |
| Source unaffected | The source environment is not impacted by refresh | Safe to refresh from production |
| Encrypted data | Some encrypted data may not transfer correctly | Test encryption-dependent features post-refresh |

[src2]

## Authentication

| Environment | Auth Endpoint | Credentials | SSO |
|---|---|---|---|
| Production | production-instance.fa.us2.oraclecloud.com | Production credentials | Production IdP |
| Sandbox (within prod) | Same as production | Same as production | Same as production |
| Test Pod | test-instance.fa.us2.oraclecloud.com | Separate credentials (or refreshed from prod) | May use separate IdP or shared |
| ATE | ate-instance.fa.us2.oraclecloud.com | Separate credentials | May use separate IdP or shared |

### Authentication Gotchas

- After an environment refresh, the test pod inherits production credentials and SSO configuration. If your production uses a specific IdP, the test pod will also require that IdP — or you need to reconfigure SSO post-refresh. [src2]
- Integration user credentials (for API access) may need to be reset after environment refresh if they rely on database-stored passwords rather than SSO. [src1]
- OAuth client IDs and secrets are environment-specific — do not reuse production OAuth credentials in the test environment. Create separate OAuth clients per environment. [src4]

## Constraints

- Sandbox changes (flexfields, Page Composer, Application Composer) are invisible to REST APIs, FBDI imports, batch processes, and other integrations until published to mainline. This is the most important limitation to understand. [src1]
- Maximum 20 open sandboxes per environment — increasing this number degrades environment performance. Oracle recommends keeping active sandboxes under 10. [src1]
- Environment refresh (test from production) requires version parity — source and target must be at the same Fusion Applications version and patch level, including monthly updates and exception updates. [src2]
- Production environments cannot be refreshed or overwritten — there is no way to "restore" production from a test environment. [src2]
- Test pod API rate limits may be lower than production — performance testing on the test pod may not reflect production performance. [src4]
- The test pod receives quarterly updates approximately 2 weeks before production — during this window, the test pod is on a newer version than production. [src3]

## Integration Pattern Decision Tree

```
START — Need to test Oracle ERP Cloud integration
├── What are you testing?
│   ├── Configuration changes (flexfields, Page Composer, App Composer)
│   │   ├── Use sandbox for isolated development
│   │   ├── Publish to mainline when ready
│   │   └── Test integrations AFTER publishing (not in sandbox)
│   ├── REST API integration
│   │   ├── Cannot test against sandbox — changes invisible
│   │   ├── Use test pod (non-production environment)
│   │   └── Verify test pod has representative data (refresh if needed)
│   ├── FBDI import process
│   │   ├── Cannot test against sandbox
│   │   ├── Use test pod with refreshed data
│   │   └── Verify UCM permissions on test pod separately
│   ├── Business Events / webhooks
│   │   ├── Cannot test against sandbox
│   │   ├── Use test pod with OIC connected to test pod
│   │   └── Separate OIC environment recommended for test
│   ├── Quarterly update regression
│   │   ├── Test pod receives update ~2 weeks before production
│   │   ├── Run full regression suite on test pod
│   │   └── ~2 week window is the only testing opportunity
│   └── Performance / load testing
│       ├── Test pod has lower rate limits — not representative
│       ├── Request dedicated performance test environment from Oracle
│       └── Or test with reduced expectations, extrapolate
├── Do you need production data?
│   ├── YES → Refresh test pod from production
│   │   ├── Schedule during maintenance window
│   │   ├── Verify version parity
│   │   └── Post-refresh: reset integration credentials
│   └── NO → Use test pod with synthetic data
└── Multiple teams need to test simultaneously?
    ├── YES → Consider purchasing ATEs
    │   └── Each ATE provides independent environment
    └── NO → Single test pod is sufficient
```

## Quick Reference

| Testing Need | Where to Test | Can Use Sandbox? | Why Not Sandbox? |
|---|---|---|---|
| New flexfield configuration | Sandbox → then test pod | Partially | Config testing yes, integration testing no |
| REST API endpoint changes | Test pod | No | Sandbox changes invisible to API |
| FBDI import template | Test pod | No | Sandbox changes invisible to FBDI |
| Business Event handlers | Test pod + OIC test | No | Sandbox changes invisible to events |
| Page Composer layout changes | Sandbox → publish → verify | Yes (for UI) | But verify integration impact on test pod |
| Groovy script validation | Sandbox | Yes | Script runs in sandbox context |
| Quarterly update regression | Test pod (~2 weeks before prod) | No | Need full environment testing |
| Performance/load testing | Dedicated environment (request from Oracle) | No | Test pod has lower limits |
| Data migration dry run | Test pod with refreshed data | No | Need representative data volume |
| Security role testing | Test pod | No | Sandbox does not test role-based access |

## Step-by-Step Integration Guide

### 1. Set Up Test Pod for Integration Testing

Ensure the test pod has representative data and integrations are pointed to the correct test endpoints. [src3, src4]

```bash
# Step 1: Verify test pod URL and access
curl -s -o /dev/null -w "%{http_code}" \
  "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1" \
  -H "Authorization: Bearer $TEST_TOKEN"
# Expected: 200

# Step 2: Check test pod version matches production
# Navigate to: Navigator → Setup and Maintenance → About This Page
# Or check via REST:
curl -s "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/serverStatus" \
  -H "Authorization: Bearer $TEST_TOKEN"
```

**Verify**: Test pod returns data and is at the same Fusion version as production (or the target upgrade version for regression testing).

### 2. Refresh Test Pod from Production

Clone production data to the test pod for representative testing. [src2]

```
# Environment refresh process:
# 1. Log in to Oracle Cloud Console (cloud.oracle.com)
# 2. Navigate to: Applications → Fusion Applications → Environments
# 3. Select target (test) environment
# 4. Actions → Refresh
# 5. Select source (production) environment
# 6. Confirm and initiate refresh

# Prerequisites:
# - Source and target at same Fusion version
# - Target environment will be unavailable during refresh
# - Plan 4-12 hours depending on data volume
```

**Verify**: After refresh completes, log in to test pod and spot-check that production data is present.

### 3. Configure Integration Endpoints for Test Pod

Update all integration configurations to point to the test pod instead of production. [src4]

```python
# Input:  Environment configuration
# Output: Environment-specific API URLs

import os

# Environment-specific configuration
ENV_CONFIG = {
    "production": {
        "base_url": "https://your-prod.fa.us2.oraclecloud.com",
        "token_url": "https://your-prod.fa.us2.oraclecloud.com/oauth/token",
        "client_id": os.environ.get("PROD_CLIENT_ID"),
        "client_secret": os.environ.get("PROD_CLIENT_SECRET"),
    },
    "test": {
        "base_url": "https://your-test.fa.us2.oraclecloud.com",
        "token_url": "https://your-test.fa.us2.oraclecloud.com/oauth/token",
        "client_id": os.environ.get("TEST_CLIENT_ID"),
        "client_secret": os.environ.get("TEST_CLIENT_SECRET"),
    }
}

# Use environment variable to select environment
current_env = os.environ.get("ORACLE_ENV", "test")
config = ENV_CONFIG[current_env]
print(f"Using environment: {current_env} ({config['base_url']})")
```

**Verify**: Integration connects to test pod (not production) — check URL in logs.

### 4. Test Sandbox-to-Mainline Publish Flow

For configuration changes, test the sandbox development and publish cycle. [src1]

```
# Sandbox workflow:
# 1. Create sandbox: Navigator → Sandboxes → Create
# 2. Make configuration changes (flexfields, Page Composer, etc.)
# 3. Test configuration visually in sandbox
# 4. Publish sandbox to mainline
# 5. Test integrations AFTER publish (not before)
# 6. If integration test fails:
#    a. Create new sandbox
#    b. Revert problematic configuration
#    c. Publish revert
#    d. Fix and try again
```

**Verify**: After sandbox publish, REST API and FBDI processes can access the new configuration.

## Code Examples

### Python: Environment-Aware Integration Client

```python
# Input:  Environment name (production/test)
# Output: Configured API client for the target environment

import requests
import os

class OracleERPClient:
    """Environment-aware Oracle ERP API client.

    Supports switching between production and test environments
    with separate credentials and endpoints.
    """
    ENVIRONMENTS = {
        "production": {
            "url": os.environ.get("ORACLE_PROD_URL"),
            "client_id": os.environ.get("ORACLE_PROD_CLIENT_ID"),
            "client_secret": os.environ.get("ORACLE_PROD_CLIENT_SECRET"),
        },
        "test": {
            "url": os.environ.get("ORACLE_TEST_URL"),
            "client_id": os.environ.get("ORACLE_TEST_CLIENT_ID"),
            "client_secret": os.environ.get("ORACLE_TEST_CLIENT_SECRET"),
        },
    }

    def __init__(self, env="test"):
        if env not in self.ENVIRONMENTS:
            raise ValueError(f"Unknown environment: {env}")
        self.config = self.ENVIRONMENTS[env]
        self.env = env
        self.token = None

    def get_token(self):
        """Obtain OAuth token for the current environment."""
        resp = requests.post(
            f"{self.config['url']}/oauth/token",
            data={
                "grant_type": "client_credentials",
                "client_id": self.config["client_id"],
                "client_secret": self.config["client_secret"],
            }
        )
        resp.raise_for_status()
        self.token = resp.json()["access_token"]
        return self.token

    def get(self, endpoint, params=None):
        """Make GET request to the configured environment."""
        if not self.token:
            self.get_token()
        url = f"{self.config['url']}{endpoint}"
        resp = requests.get(url,
            headers={"Authorization": f"Bearer {self.token}"},
            params=params, timeout=30)
        return resp

# Usage
client = OracleERPClient(env=os.environ.get("ORACLE_ENV", "test"))
client.get_token()
pos = client.get("/fscmRestApi/resources/11.13.18.05/purchaseOrders", {"limit": 5})
print(f"[{client.env}] PO count: {pos.json().get('count')}")
```

### cURL: Verify Test Pod Health

```bash
# Input:  Test pod URL and token
# Output: Health check results

# Test 1: API endpoint accessible
echo "Checking API access..."
curl -s -o /dev/null -w "HTTP %{http_code}\n" \
  "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1" \
  -H "Authorization: Bearer $TEST_TOKEN"

# Test 2: Check data freshness (last PO creation date)
echo "Checking data freshness..."
curl -s "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1&orderBy=CreationDate:desc&fields=OrderNumber,CreationDate" \
  -H "Authorization: Bearer $TEST_TOKEN" | python -c "
import sys,json; d=json.load(sys.stdin)
items = d.get('items',[])
if items: print(f'Latest PO: {items[0].get(\"OrderNumber\")} created {items[0].get(\"CreationDate\")}')
else: print('No POs found — data may need refresh')"

# Test 3: Check UCM access (for FBDI testing)
echo "Checking UCM access..."
curl -s -o /dev/null -w "HTTP %{http_code}\n" \
  "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/erpintegrations" \
  -H "Authorization: Bearer $TEST_TOKEN"
```

## Data Mapping

### Environment Feature Comparison

| Feature | Production | Sandbox (in prod) | Test Pod | ATE |
|---|---|---|---|---|
| URL | prod.fa.*.oraclecloud.com | Same as production | test.fa.*.oraclecloud.com | ate.fa.*.oraclecloud.com |
| Data | Production data | Same as production | Refreshable from prod | Refreshable from prod |
| API Endpoints | /fscmRestApi/* | Same as production | Separate /fscmRestApi/* | Separate /fscmRestApi/* |
| Config changes | Mainline only | Isolated in sandbox | Independent | Independent |
| OAuth clients | Production-specific | Same as production | Environment-specific | Environment-specific |
| Rate limits | Full production | Same as production | May be lower | May be lower |
| SSO/IdP | Production IdP | Same as production | Configurable | Configurable |
| Update schedule | Quarterly (A/B/C/D) | Same as production | ~2 weeks before prod | Configurable |

### Data Type Gotchas

- After environment refresh, all passwords in the test pod are reset to the default — integration service accounts need password updates. [src2]
- Encrypted data (e.g., credit card tokens, encrypted attachments) may not transfer correctly during refresh — test encryption-dependent features post-refresh. [src2]
- UCM content (uploaded files, FBDI templates) may not fully transfer during refresh — verify UCM content availability post-refresh. [src2]

## Error Handling & Failure Points

### Common Error Codes

| Code | Meaning | Cause | Resolution |
|---|---|---|---|
| 401 Unauthorized | Auth failed on test pod | Credentials not configured for test environment | Create separate OAuth client for test pod |
| 403 Forbidden | Missing role on test pod | Roles not refreshed or configured | Re-assign roles post-refresh |
| 404 Not Found | Endpoint not available | Test pod at different version | Verify version parity |
| SANDBOX-INVISIBLE | Config change not visible to API | Sandbox not published | Publish sandbox to mainline first |
| REFRESH-VERSION-MISMATCH | Cannot refresh | Source/target version mismatch | Apply patches to match versions |
| REFRESH-TIMEOUT | Refresh incomplete | Large data volume or network issue | Retry during lower-traffic window |

### Failure Points in Production

- **Testing integrations against sandbox**: Developers configure flexfields in a sandbox and try to test REST API access to those fields — the fields are invisible. Fix: Always publish sandbox to mainline before testing integrations. Test integrations on the test pod, not in sandboxes. [src1]
- **Forgotten credential reset after refresh**: After refreshing test pod from production, integration service account passwords may be reset. Integrations fail with 401. Fix: Reset service account passwords immediately after environment refresh and update integration configurations. [src2]
- **Version mismatch blocking refresh**: The test pod receives quarterly updates before production. During the ~2 week window when test pod is on 25D and production is on 25C, you cannot refresh test from production. Fix: Perform environment refresh before the quarterly update window, not during it. [src2]
- **Lower test pod rate limits causing false failures**: Integration performance tests pass on test pod but reveal rate limiting issues in production (or vice versa). Fix: Do not rely on test pod for performance benchmarks — request a dedicated performance test environment from Oracle if needed. [src4]

## Anti-Patterns

### Wrong: Testing Integrations in Sandbox Context

```
// ❌ BAD — Configuring flexfields in sandbox, then testing REST API
// The REST API cannot see sandbox-only changes
// Developer wonders why the new field doesn't appear in API responses
// Wastes hours debugging a non-existent API bug
```

### Correct: Publish Sandbox, Then Test on Test Pod

```
// ✅ GOOD — Development in sandbox, testing after publish
// Step 1: Configure flexfield in sandbox (visual testing only)
// Step 2: Publish sandbox to mainline
// Step 3: Refresh test pod from production (gets published config)
// Step 4: Test REST API on test pod — field is now visible
```

### Wrong: Using Production Credentials for Test Pod

```python
# ❌ BAD — Same OAuth client for production and test
client_id = "PROD_CLIENT_ID"  # Works in both? No — security risk
client_secret = "PROD_SECRET"
# Risk: Test code accidentally hits production
```

### Correct: Separate Credentials Per Environment

```python
# ✅ GOOD — Environment-specific credentials
if env == "test":
    client_id = os.environ["TEST_CLIENT_ID"]
    client_secret = os.environ["TEST_CLIENT_SECRET"]
    base_url = os.environ["TEST_URL"]
elif env == "production":
    client_id = os.environ["PROD_CLIENT_ID"]
    client_secret = os.environ["PROD_CLIENT_SECRET"]
    base_url = os.environ["PROD_URL"]
# Impossible to accidentally hit wrong environment
```

### Wrong: Refreshing Test Pod During Quarterly Update Window

```
// ❌ BAD — Trying to refresh when versions don't match
// Test pod: 25D (updated 2 weeks ago)
// Production: 25C (not yet updated)
// Refresh fails: version mismatch error
```

### Correct: Refresh Before Quarterly Update Window

```
// ✅ GOOD — Refresh while versions are aligned
// Week -3: Refresh test pod from production (both on 25C)
// Week -2: Test pod receives 25D update
// Week -2 to 0: Run regression tests on 25D
// Week 0: Production receives 25D update
```

## Common Pitfalls

- **Confusing sandbox with test environment**: Sandboxes are configuration isolation within an environment. The test pod is a separate environment with its own data and API endpoints. Sandboxes cannot be used for integration testing. Fix: Use the test pod for all integration testing. [src1]
- **Not refreshing test pod data before testing**: Stale test pod data may not reflect production realities (missing suppliers, outdated GL segments, etc.). Fix: Refresh test pod from production before major testing cycles. [src2]
- **Assuming test pod performance equals production**: Test pods typically have lower resource allocation and may have different rate limits. Fix: Do not use test pod performance numbers as production benchmarks. Request a dedicated performance environment if needed. [src4]
- **Opening too many sandboxes**: More than 10 active sandboxes degrades environment performance for all users. Fix: Close sandboxes after publishing, keep active count under 10. [src1]
- **Not planning for the quarterly update version gap**: During the ~2 week window when test pod and production are on different versions, refresh is blocked. Fix: Schedule data refreshes outside the quarterly update window. [src2]

## Diagnostic Commands

```bash
# Check test pod accessibility
curl -s -o /dev/null -w "HTTP %{http_code}\n" \
  "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1" \
  -H "Authorization: Bearer $TEST_TOKEN"

# Verify data freshness (latest record dates)
curl -s "https://your-test-instance.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=1&orderBy=CreationDate:desc" \
  -H "Authorization: Bearer $TEST_TOKEN" | python -m json.tool

# Compare record counts between production and test
echo "Production PO count:"
curl -s "https://your-prod.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=0&totalResults=true" \
  -H "Authorization: Bearer $PROD_TOKEN" | python -c "import sys,json; print(json.load(sys.stdin).get('totalResults', 'N/A'))"

echo "Test PO count:"
curl -s "https://your-test.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseOrders?limit=0&totalResults=true" \
  -H "Authorization: Bearer $TEST_TOKEN" | python -c "import sys,json; print(json.load(sys.stdin).get('totalResults', 'N/A'))"

# Check open sandbox count (via UI)
# Navigate to: Navigator → Sandboxes → count open sandboxes
```

## Version History & Compatibility

| Release | Date | Status | Environment Changes | Impact |
|---|---|---|---|---|
| 25D | 2025-11 | Current | Enhanced refresh monitoring | Positive |
| 25C | 2025-08 | Supported | Updated environment refresh process | Minor |
| 25B | 2025-05 | Supported | No environment changes | — |
| 25A | 2025-02 | Supported | Sandbox publish performance improved | Positive |

[src2, src3]

### Deprecation Policy

Oracle does not deprecate testing environment capabilities. The sandbox mechanism, test pod provisioning, and environment refresh features are considered core platform capabilities and have been stable since Oracle Fusion Cloud's initial release. However, the specific refresh process UI and options may change with quarterly updates. [src3]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Planning integration testing strategy | Need to understand customization options | business/erp-integration/oracle-erp-cloud-customization-boundaries/2026 |
| Setting up test environment for API testing | Need quarterly update regression approach | business/erp-integration/oracle-erp-cloud-upgrade-impact-integrations/2026 |
| Troubleshooting "invisible" config in API | Need FBDI-specific troubleshooting | business/erp-integration/oracle-fbdi-common-failures/2026 |

## Important Caveats

- Sandboxes isolate configuration only — not data, not API endpoints, not integrations. This is the most misunderstood aspect of Oracle Cloud ERP testing.
- Test pod resource allocation may differ from production — performance testing results may not be transferable.
- Environment refresh requires version parity and causes target downtime — plan refreshes carefully.
- After environment refresh, all integration credentials, SSO configurations, and UCM permissions should be verified before testing.
- The standard subscription includes only 1 test environment — multiple teams testing simultaneously may require purchasing ATEs.

## Related Units

- [Oracle ERP Cloud Customization Boundaries](/business/erp-integration/oracle-erp-cloud-customization-boundaries/2026)
- [Oracle ERP Cloud Quarterly Update Impact on Integrations](/business/erp-integration/oracle-erp-cloud-upgrade-impact-integrations/2026)