> ## Documentation Index
> Fetch the complete documentation index at: https://docs.taketime.space/llms.txt
> Use this file to discover all available pages before exploring further.
# Test Your Integration Safely with Take Time Sandbox Mode
> Use Take Time sandbox (tt_test_) API keys during development. Test keys give you full API access without affecting your real study data or streak.
Take Time provides a sandbox environment through test API keys — prefixed `tt_test_` — that give you full API access without touching your real study data. Use sandbox keys during development and integration testing. When you're ready to ship, swap the prefix and your code works against live data with no other changes required.
## Test vs live keys
The only difference between sandbox and production is which dataset your requests read and write. The API surface, request shapes, and error codes are identical across both environments.
| Key prefix | Data affected | Use for |
| ---------- | -------------------- | ----------------------- |
| `tt_live_` | Your real study data | Production integrations |
| `tt_test_` | Isolated sandbox | Development and testing |
Test and live keys are generated separately. A `tt_test_` key can never accidentally write to your live data — the environments are fully isolated.
## Generate a test key
In the Take Time app, tap the **Settings** tab in the bottom navigation bar.
Scroll to the **Developer** section and tap it to expand the developer options.
Tap **Generate API Key**. In the key creation dialog, select the **Sandbox (tt\_test\_)** option before confirming.
Copy the key immediately — Take Time shows it only once. Store it in a `.env` file or your secrets manager. If you lose it, revoke it and generate a new one.
Treat test keys with the same care as live keys. Anyone who holds a `tt_test_` key can read and modify your sandbox data, including any fixture blocks or test activities you've created.
## Using test keys
Swap the key prefix to switch environments. Every endpoint, request body, and response shape is identical — only the data changes.
```javascript Node.js (sandbox) theme={null}
const res = await fetch('https://api.taketime.app/v1/blocks?date=2025-01-15', {
headers: { 'Authorization': 'Bearer tt_test_your_key_here' }
});
const { data, error } = await res.json();
console.log('Sandbox blocks:', data);
```
```javascript Node.js (production) theme={null}
const res = await fetch('https://api.taketime.app/v1/blocks?date=2025-01-15', {
headers: { 'Authorization': 'Bearer tt_live_your_key_here' }
});
const { data, error } = await res.json();
console.log('Live blocks:', data);
```
```bash cURL (sandbox) theme={null}
curl "https://api.taketime.app/v1/blocks?date=2025-01-15" \
-H "Authorization: Bearer tt_test_your_key_here"
```
The API base URL (`https://api.taketime.app/v1`) is the same for both environments. The key prefix is the only routing signal — no separate subdomain or endpoint path is needed.
## Sandbox limitations
The sandbox behaves like production in almost every way, but there are a few intentional differences:
* **Data is isolated.** Blocks, activities, subjects, and stats created with a test key exist only in your sandbox. They never appear in the live app or affect your streak and heatmap.
* **Rate limits apply.** The same request-per-minute and request-per-day limits from your plan tier are enforced in sandbox mode. Build rate-limit handling early so it works correctly in production.
* **Push notifications do not fire.** Sandbox blocks do not trigger push alerts, even if notifications are enabled in the app. This prevents test runs from generating noise on your devices.
Seed your sandbox with realistic fixture data before running integration tests. Use `POST /v1/blocks` with your test key to create a consistent baseline you can reset between test runs.
## Switching between environments
Use an environment variable to control which key your code uses. This pattern makes it trivial to switch environments without changing source code, and it keeps secrets out of version control.
```bash Terminal theme={null}
# Use the sandbox during development
export TAKETIME_API_KEY=tt_test_your_key_here
# Switch to production before deploying
export TAKETIME_API_KEY=tt_live_your_key_here
```
```javascript Node.js theme={null}
const API_KEY = process.env.TAKETIME_API_KEY;
if (!API_KEY) {
throw new Error('TAKETIME_API_KEY environment variable is not set.');
}
// Detect environment from the key prefix for logging
const env = API_KEY.startsWith('tt_test_') ? 'sandbox' : 'production';
console.log(`Take Time client initialized in ${env} mode.`);
async function request(path, options = {}) {
return fetch(`https://api.taketime.app/v1${path}`, {
...options,
headers: {
'Authorization': `Bearer ${API_KEY}`,
'Content-Type': 'application/json',
...options.headers
}
});
}
```
## Go-live checklist
Before you deploy your integration to production, work through this checklist:
* [ ] Replace the `tt_test_` key with your `tt_live_` key in your production secrets store
* [ ] Store the live key in a secrets manager — not in source code or `.env` files committed to version control
* [ ] Confirm the API key is never exposed in client-side JavaScript or public API responses
* [ ] Review the rate limits for your plan tier and verify your integration stays within them under peak load
* [ ] Test all error-handling paths using intentionally bad requests (invalid IDs, missing fields) to confirm your error handling works end-to-end
* [ ] Set up key rotation: schedule a reminder to regenerate your live key periodically and update it in your secrets store
If you suspect a live key has been exposed — for example, committed to a public repository — revoke it immediately in **Settings → Developer** before generating a replacement. Revocation takes effect instantly.