API credentials
To access the API, your own applications need API credentials.
You'll find them under Profile & settings → API credentials.
Personal and far-reaching
These are your personal API credentials. They are needed to use the API. Your personal API credentials grant access to all data in your Spaces. Only share these credentials with third-party services and applications you trust.
Two things about this matter:
- Personal, not tied to a Space. The credentials reach as far as your own access — across all your Spaces, even ones unrelated to the project at hand.
- They're tied to your account. If someone leaves the company and their account gets deleted, every integration built with those credentials stops working.
Creating credentials
- Click Create credentials.
- Give them a name under Choose a name for your credentials.
- Choose the permission under These credentials grant:.
- Confirm with Create.
Permission
| Choice | Scope |
|---|---|
| Admin | Full access to your Spaces |
| Read only | Read-only access to your Spaces |
When in doubt, "Read only"
For reports, evaluations, and data exports, read access is enough. Choose Admin only when the application genuinely needs to write.
A read error in a script with read-only access costs nothing. The same error with full access can overwrite data.
Separate credentials per application
Don't create one key for everything — create one per application, with a descriptive name. That way you can revoke individual ones without disabling everything else.
Visible only once
Note them down immediately
After creation, this appears:
Your credentials are available
Save your authorization key and your password now.
This is the only time the credentials can be viewed or downloaded. They cannot be recovered later. However, you can delete your API credentials at any time and generate new ones.
The credentials consist of an authorization key and a password.
Store both in a password manager — not in a text file, a chat, or an email.
If something gets lost, delete the credentials and generate new ones. The integration will then need to be updated.
Security
Where credentials don't belong
- Not in public repositories. Automated scanners find keys like this within minutes.
- Not in frontend code. Anything that runs in the browser can be inspected.
- Not in chats, tickets, or slides.
- Not in screenshots.
Clean up regularly
Go through your list of credentials and delete what's no longer needed. A forgotten key stays valid until someone removes it.
How to recognize API access
Entries created via the API show the value API credentials in the Created by column, instead of a person's name.
In the version history, corresponding changes appear as System or Flow.
Useful for troubleshooting
If a value changes unexpectedly, the version history quickly clarifies whether a person, a Flow, or a connected application is behind it.
Technical details
For building an integration:
| Property | Value |
|---|---|
| API version | 2 |
| Structure | resources reference each other via links |
| Authentication | authorization key and password |
| Space identifier | in Space settings under Space identifier |
| Field identifiers | via Manage field key on the respective field |
The full API reference
Every endpoint, authentication, filters, and error codes are documented in the REST API reference, along with a machine-readable openapi.json. The API reference is currently available in German only.
Do you really need the API?
Often there's a simpler way
| Goal | Simpler path |
|---|---|
| Pull in data from a system | CSV import |
| Hand data to a system | CSV export or Webhook |
| Call another system | Flow step HTTP request |
| Start a Flow from outside | Webhook trigger |
| Display data | Portal |
The API is worth it when your own application works with ApptiveGrid continuously, in both directions.