Sandbox Mode
The Rekall sandbox provides a fully isolated testing environment with dedicated rk_test_ keys. Sandbox data is completely separate from production -- you can create, read, update, and delete memories without affecting your real data.
Free to Use
The sandbox environment is free on all plans. API calls made with sandbox keys do not count toward your production usage limits or billing.
Creating Sandbox Keys
Sandbox keys are created in the same way as production keys, but with the test environment selected. They are automatically prefixed with rk_test_.
Via Dashboard
- Navigate to Settings → API Keys
- Toggle the environment switch to Sandbox
- Click Create New Key
- Give the key a descriptive name (e.g., "Local Dev" or "CI Tests")
- Select the scopes you want to test with
- Click Generate
import Rekall from '@rekall/sdk';// The SDK automatically detects sandbox mode from the key prefixconst rekall = new Rekall({apiKey: process.env.REKALL_TEST_KEY, // rk_test_...});// All operations are routed to the sandbox environmentconst memory = await rekall.memories.create({type: 'episodic',content: 'Test memory for development',context: { source: 'unit-test' },});console.log(memory.id); // Sandbox memory IDconsole.log(memory.environment); // "sandbox"
Sandbox Environment
The sandbox mirrors the production API with the same endpoints, request formats, and response structures. The only differences are data isolation and rate limits.
Data Isolation
Sandbox and production environments are completely isolated:
Production
- checkKeys prefixed with
rk_ - checkReal user data and memories
- checkFull rate limits and SLAs
- checkUsage counts toward billing
Sandbox
- checkKeys prefixed with
rk_test_ - checkIsolated test data only
- checkReduced rate limits
- checkFree, no billing impact
No Cross-Environment Access
Sandbox keys cannot access production data, and production keys cannot access sandbox data. There is no way to bridge between environments. If you need to seed sandbox data, use the sandbox key to create it.
Sandbox Limitations
While the sandbox mirrors production functionality, there are some differences to be aware of:
| Feature | Production | Sandbox |
|---|---|---|
| Memory storage | Unlimited (per plan) | 10,000 memories |
| Entity limit | Unlimited (per plan) | 5,000 entities |
| Embedding model | Latest production model | Same model, lower priority |
| Webhook delivery | Guaranteed delivery with retries | Best-effort, no retries |
| Data retention | Per your plan settings | 30 days (auto-purged) |
| Concurrent connections | Per plan limits | 5 concurrent |
| Batch operations | Up to 1,000 items | Up to 100 items |
| SSO testing | Full SSO support | Mock SSO only |
Rate Limits
Sandbox rate limits are lower than production to ensure fair shared resource usage:
| Limit Type | Production | Sandbox |
|---|---|---|
| Requests per minute | 1,000 RPM | 60 RPM |
| Requests per day | 100,000 RPD | 5,000 RPD |
| Burst limit | 50 concurrent | 10 concurrent |
| Memory creation | 100/minute | 20/minute |
| Search queries | 200/minute | 30/minute |
Rate Limit Headers
Sandbox responses include the same rate limit headers as production: x-ratelimit-limit, x-ratelimit-remaining, and x-ratelimit-reset. Use these to test your rate limit handling logic.
Testing Workflows
The sandbox is ideal for testing complete workflows before deploying to production:
import Rekall from '@rekall/sdk';// Use sandbox key for testsconst rekall = new Rekall({apiKey: process.env.REKALL_TEST_KEY, // rk_test_...});// Test the complete memory lifecycleasync function testMemoryLifecycle() {// Createconst memory = await rekall.memories.create({type: 'episodic',content: 'User asked about pricing plans',context: { sessionId: 'test-session-001' },});console.assert(memory.id, 'Memory should have an ID');// Readconst fetched = await rekall.memories.get(memory.id);console.assert(fetched.content === memory.content);// Searchconst results = await rekall.memories.search({query: 'pricing plans',limit: 5,});console.assert(results.length > 0, 'Search should return results');// Updateconst updated = await rekall.memories.update(memory.id, {metadata: { resolved: true },});console.assert(updated.metadata.resolved === true);// Deleteawait rekall.memories.delete(memory.id);console.log('Memory lifecycle test passed!');}testMemoryLifecycle();
Transitioning to Production
When you are ready to move from sandbox to production, follow these steps:
- Create a production API key
Go to Settings → API Keys and create a key with the Production environment selected.
- Update your environment variables
Replace
rk_test_...withrk_...in your deployment configuration. - Apply the same scopes
Ensure the production key has the same scopes you tested with in sandbox.
- Deploy and verify
No code changes are required. The API base URL and all endpoints are the same.
- Monitor production usage
Check the dashboard for production request metrics and error rates.
# Development / CIREKALL_API_KEY=rk_test_abc123def456...# ProductionREKALL_API_KEY=rk_xyz789uvw012...# No code changes needed -- the SDK detects the environment from the prefix
No Code Changes
The Rekall SDK and API behave identically in both environments. Switching from sandbox to production only requires changing the API key. No URL changes, no code changes, no configuration changes.
Sandbox Reset
You can reset your sandbox environment to a clean state at any time. This deletes all sandbox data including memories, entities, relationships, and workflows.
// Reset the entire sandbox environmentawait rekall.sandbox.reset();// Verify the resetconst memories = await rekall.memories.list();console.log(memories.length); // 0// Optionally seed with test data after resetawait rekall.sandbox.seed({memories: 50, // Create 50 sample memoriesentities: 20, // Create 20 sample entitiesrelationships: 10, // Create 10 sample relationships});
Irreversible
Sandbox reset is irreversible. All sandbox data is permanently deleted. This action does not affect production data in any way.
