Secret Keys
Manage API authentication credentials for programmatic access to Datature Vi.
Secret keys are the credentials that authenticate your applications and scripts with Datature Vi. When you initialize the Vi SDK or call the REST API directly, you pass a secret key to identify your organization and authorize the request.
Secret keys authenticate your Vi SDK and API requests. Learn what Datature Vi does or follow the quickstart.
Secret keys grant access to your entire organization. Store them in environment variables or a secrets manager. Never commit them to version control or expose them in client-side code.
Create and manage secret keys to authenticate the Vi SDK and API.
What are secret keys?
Each secret key is tied to your organization and carries a set of permissions that control what it can do. You create keys through the Datature Vi settings panel, copy the key value once (it's only shown at creation), and then pass it to the SDK or API.
Keys appear in a table on the Secret Keys page with the following columns:
When do you need a secret key?
You need a secret key any time you access Vi programmatically:
If you need a one-page RACI template (who creates keys, who approves production credentials, who owns billing), pair this guide with Roles and RACI checklist.
Access scope and permissions
When you create a key, you configure two things:
Access scope controls which resource categories the key can reach:
- Dataset Access: datasets and annotations
- Training Access: training workflows and runs
- Deployment Access: model deployments and inference
Permission level controls what actions the key can take:
- Full: complete read and write access
- Read Only: view data and model information, no modifications
- Labeler Only: create and modify annotations only
- Restricted: custom limited access
Granular access scope configuration is not available for all organizations. By default, keys have access to all resources. Contact your account manager to enable per-scope controls.
Security best practices
Use separate keys per environment. Create distinct keys for production, staging, development, and CI/CD. That way, a compromised development key doesn't affect your production system.
Rotate keys on a schedule. A good starting point: every 90 days for production and CI/CD keys, every 180 days for staging, and as needed for development.
Audit regularly. Check the Last Used column to identify keys that haven't been used in a long time. Delete them to shrink your attack surface.
If a key is compromised, act immediately:
Delete the compromised key
Create a replacement key
Update all applications that used the old key
Review recent activity for unauthorized access
Notify your team
Next steps
Updated 27 days ago
