Managing REST API authentication keys
Each project requires a separate key to authenticate you via the API. Anyone in possession of one of these keys can perform actions as you, but only within the project to which the key belongs.
You can generate API keys from your Loco project dashboard at any time. Click the :wrench icon: in the top-right project. This opens the "Developer tools" window, and you will see two types of keys:
1. Export key
Primarily intended for deployment scripts, this type of key provides read only access across the API.
Nobody in possession of this key can do any damage to your data, because any updates or deletions attempted with such a key will be blocked.
In other words, this type of key can only be used for GET requests.
We store export keys in the clear in our database, so you can retrieve them from the Developer tools window at any time.
2. Full access key
This key provides read and write access to your Loco project. For this reason you should treat it as carefully as you would your password. Anyone in possession of this key can update and delete your project data as if they were you.
If you need to distribute your key into a deployment script, or share download links with colleagues, use a read-only export key instead.
Full access keys are not stored in our database. This means you can't retrieve them once you close the Developer tools window. Be sure to copy new keys to a secure location of your own. If you lose your key, you'll have to generate a new one.
Authentication and usage
Loco API keys are effectively "bearer" tokens. This means there's no need to sign requests or present any additional secret information.
To authenticate with your key, simply send it to the API as a query string key parameter or [preferably] as an authentication header when possible.
See full technical details in the API docs.
We recommend that full access keys are always sent in the header as Authorization: Loco <key>. This avoids your key appearing in our log files.
Security notes
- The Loco API operates only over SSL. Be sure to verify secure connections;
- Treat your keys as sensitively as passwords and regenerate them regularly (they don't expire);
- Use a read-only key whenever possible, especially when distributing links or deployment code.