Authentication
Create an API key, send it as a bearer token, and understand exactly what it can reach.
Every Public API v1 request is authenticated with a workspace API key. There is no separate API user: a key acts as the person who created it, limited to a single workspace.
Create a key
- Open Settings and go to the API keys section.
- Create a key, name it after the integration that will use it, and choose what it may reach: read-only or read and write, and all surveys or one.
- Copy the secret into your secret store before closing the dialog.
Important The full key is shown once, at creation. Asqiro stores only a hash of it, so a lost key cannot be recovered - create a new one and delete the old.
Send a request
Pass the key in the Authorization header. Keys start with asq_ and must never be sent in a query string, committed to a repository, or embedded in browser code.
bash
export ASQIRO_API_KEY="asq_your_key_here"
curl "https://www.asqiro.com/api/v1/surveys" \
-H "Authorization: Bearer $ASQIRO_API_KEY"A valid key returns 200 with a JSON body. An invalid, deleted, or expired key returns 401 with the code unauthorized.
What a key can reach
- One workspace. A key never sees surveys in another workspace, even one the same person belongs to.
- Its own access level. A read-only key answers 403 with the code forbidden on any write, whatever its creator is allowed to do.
- The surveys it was limited to, if any. Such a key lists only those surveys, and answers 404 for every other survey id, exactly as it would for one that does not exist.
- The access of the user who created it. If that person loses workspace access, every key they made stops working.
- Their workspace role. A viewer's key can read, but write calls answer 403 with the code forbidden.
- An eligible plan. If the workspace owner's plan does not include API access, requests answer 403 with the code plan_upgrade_required.
Note Keys created before access levels existed keep full read and write access to their whole workspace. Re-issue them if a narrower key is what you want.
Rotate and revoke
To rotate, create the replacement key first, deploy it, then delete the old key. Deleting takes effect immediately, so removing the old key before the new one is live will interrupt your integration.
Note Deleting a workspace member revokes every key that member created. Plan for this before an employee offboarding rather than after it.