Authentication

Client-facing endpoints accept an API key passed in the X-API-Key header. Keys are created and managed from the dashboard, and can be rotated or deactivated at any time.

A couple of endpoints need no credential: GET /billing/plans (so a logged-out pricing page can list plans) and GET /health.

API key format

Datapoint API keys start with the prefix dp_live_ followed by 48 hexadecimal characters (56 characters in total):

dp_live_7a9495179792eb18e050fa5f5a45bd82d5dfc42bc6156224

There is a single API base URL and a single dp_live_ prefix — there is no separate sandbox host or test-key prefix. To run against the free test environment, set serving_environment: "sandbox" on a job rather than using a different key.

Keys are stored hashed (SHA-256) server-side. The raw key is shown once at creation. If you lose it, create a new one.

Sending the key

Pass the key as an X-API-Key header on every request:

curl https://api.trydatapoint.com/data-labelling/v1/jobs \
  -H "X-API-Key: dp_live_..."

Creating a key

From the dashboard's API keys page, click Create key. You can set:

• Label: a human-readable name (e.g. production-server, local-dev). The label is not private — it is returned as api_key_label on every job the key creates (see GET /jobs), visible to any credential in your organization.
• Rate limit (RPM): requests per minute for this key, from 1 to 1000. Defaults to 60.

The raw key appears once, then disappears. Store it somewhere safe, such as a secret manager, .env file (outside git), or your platform's secure config.

Keys may also appear in this list when they are minted from the plugin or CLI sign-in flow.

Rotating a key

To rotate without downtime:

1. Create a new key in the dashboard.
2. Deploy the new key to your application.
3. Confirm your application is sending the new key (check your own request logs or monitoring).
4. Deactivate the old key.

Each key has its own rate-limit bucket, so both keys can coexist during rollover.

Deactivating a key

Deactivating a key from the dashboard stops it working immediately; subsequent requests with that key return 401 Unauthorized. The key is not deleted — it remains in your key list marked as inactive, so its label and history stay visible.

{
  "detail": "Invalid or inactive API key",
  "message": "Invalid or inactive API key"
}

Security best practices

• Use separate keys for separate integrations. Distinct keys for your production server, CI, and local development make rotation and log correlation cleaner. For test runs, point a job at serving_environment: "sandbox" — it runs free — rather than using a different key.
• Set a realistic rate limit. If a key only hits the API from a single CI job, 60 RPM is plenty. A lower cap limits the blast radius of a leaked key.
• Rotate on the slightest suspicion. Keys are meant to be cheap to rotate.
• Never expose keys in client-side code. Datapoint keys must only be used from server-side code you control. A browser-facing integration should proxy through your backend.
• Treat every key as organization-wide. Because any key can read all jobs and spend the shared balance, deactivate keys you no longer recognize.

Next

• Errors: what goes wrong and how to recover
• Rate limits: understanding per-key throughput