The SDK and the API authenticate with an API key that belongs to your organization. Manage keys at Settings → API keys (/app/settings).
One key per sender
An organization can have as many keys as it needs. Create one for each developer, server or CI job that runs the SDK, and give it a name that says where it lives, such as "Ana's laptop" or "GitHub Actions". Every key writes into the same organization, so batches from all of them land in one account.
The keys page shows each key's name, mode, who created it and when it was last used. Each batch records the key that sent it, and the SDK also sends a client string with its version and the machine's hostname, so the portal can show who sent what.
Test and live keys
| Prefix | Use |
|---|---|
dy_test_ |
Setting up and trying the SDK. Batches sent with a test key never become billable and are never delivered to buyers. |
dy_live_ |
Real deliveries. Use it once datayield preview looks right. |
Each key is shown once, when you create it. We store only a hash of it, so we cannot show it to you again. If you lose a key, create a new one and revoke the old one.
Where the SDK keeps the key
datayield init stores the key in ~/.datayield/credentials, a file only your user can read. On CI, set the DATAYIELD_API_KEY environment variable instead; it takes precedence over the file. Never put the key in datayield.config.json or commit it to source control. For scheduled runs on GitHub Actions, store it as a repository secret. See Scheduling.
Checking which key is in use
GET /api/v1/me returns the organization and the key's mode (test or live). See Authentication.
Revoking a key
Revoke a key from the same page. A revoked key can no longer send batches, and data it already sent is not affected. If a key leaks, revoke it straight away and give that sender a new key. Because each sender has its own key, revoking one does not stop the others.