Skip to main content
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 prefixData affectedUse for
tt_live_Your real study dataProduction integrations
tt_test_Isolated sandboxDevelopment 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

1

Open Settings

In the Take Time app, tap the Settings tab in the bottom navigation bar.
2

Navigate to Developer

Scroll to the Developer section and tap it to expand the developer options.
3

Generate an API key

Tap Generate API Key. In the key creation dialog, select the Sandbox (tt_test_) option before confirming.
4

Copy and store the key

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. 
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);
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.
Terminal
# 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
Node.js
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.