API keys and connected apps

Styrar offers two common integration styles: API keys for your own scripts and servers, and connected apps for third-party products users authorize through OAuth. Both can access workspace data according to granted capabilities, but they are meant for different situations.

Use API keys when you control the code that will call Styrar, such as an internal script, server job, workflow runner, or MCP client using a bearer token. Use connected apps when an external product asks a user to approve access through a consent screen.

API keys

Under Settings → API keys, create keys for automation and backend jobs. Treat keys like passwords: store them securely, rotate if exposed, and revoke keys you no longer use. Do not paste live keys into public code, screenshots, tickets, or client-side browser code.

Good API key practices:

• Create separate keys for separate systems.
• Give each key a recognizable name.
• Grant only the capabilities the integration needs.
• Store keys in a secrets manager or server environment variable.
• Rotate keys when team members change or logs might have exposed them.
• Revoke old test keys after setup is complete.

If a script fails with an authorization error, check whether the key has the required capability and belongs to the expected personal or company workspace. A key created in one scope may not have access to resources in another.

For MCP clients, use the Styrar API key as the bearer token when the client asks for a remote HTTP MCP token or when configuring stdio mode with an environment variable. OAuth client ID and client secret fields in some tools are not the same thing as a dashboard API key.

Connected apps

Under Settings → Connected apps, review OAuth applications that users have approved. Each entry shows what was granted. Disconnect anything that should no longer access the workspace. Connected apps are tied to real user consent, so each user should periodically review which products they have authorized.

An app may request read access, write access, or a mix of capabilities. The final granted access can be limited by the app's own allowlist, the user's consent, and the user's permissions in the workspace. If an app cannot perform an action, it may need re-authorization after scopes or product capabilities change.

Disconnecting an app stops future access through that OAuth grant. If the third-party product also stores data on its side, check that product's settings if you want to remove its local copy or integration state.

OAuth consent

Third-party apps send people through a consent screen. Users should only approve apps they trust and that match the tool they intended to connect. Read the requested access before approving. If the app asks for more access than expected, cancel and verify the integration documentation.

For teams, decide who is allowed to connect third-party apps. Some workspaces keep OAuth approval limited to owners or admins. Others allow members to connect productivity tools but restrict billing, company settings, or publishing scopes.

Choosing the right integration

Choose an API key when:

• The integration runs on your server.
• There is no individual user approval flow.
• You need a stable credential for automation.
• You can store secrets securely outside the browser.

Choose OAuth when:

• A third-party product is connecting on behalf of a user.
• The user should review a consent screen.
• Access should be revocable per app.
• The integration needs to respect each user's workspace permissions.

If a key or app is exposed

Revoke it immediately from settings. Create a replacement only after you understand where the old credential was stored. If the exposed credential had write access, review recent activity and audit logs where available.

Need more help?

Open a ticket from Help → Tickets (sign in required).