Applications and integrations in Usable
Bergur DavidsenUpdated 2026-07-14
Usable applications provide a managed identity and connection model for formal integrations. They complement personal access token scripts, REST services, MCP clients, marketplace apps, and embedded experiences.
Choose the smallest integration model that meets the need. A one-off private script usually does not need a marketplace application.
Main application surfaces
The released dashboard includes:
- Marketplace at
/dashboard/marketplacefor discovery; - app details at
/dashboard/marketplace/{appId}; - Installed Apps at
/dashboard/marketplace/installed; - Applications at
/dashboard/applicationsfor apps you own or administer; - application creation and detail pages beneath
/dashboard/applications.
Visibility and available controls depend on the account, application status, install policy, and the user's app role.
Application versus integration
An application is a managed record with developer metadata, connection settings, grants, permissions, access policy, administrators, and lifecycle status.
An integration is the working connection between systems. It can use:
- an application and OAuth flow;
- a Device Authorization Grant;
- a service credential where supported;
- a dedicated PAT for a private REST or MCP client;
- a dashboard or embedded connection flow.
Creating an application does not automatically install it, authorize a user, or grant workspace access.
Choose an integration model
Use a dedicated PAT script when:
- one trusted service performs a narrow internal task;
- there is no end-user consent flow;
- the token can remain server-side;
- workspace scope and rotation are manageable.
Use an application when:
- multiple users or organizations connect;
- consented scopes are needed;
- browser, desktop, mobile, or device flows are required;
- install eligibility must be controlled;
- app ownership and lifecycle need management;
- marketplace discovery is appropriate.
Use MCP when an AI client should select Usable tools. Use REST when software already knows the deterministic operation.
Marketplace, installed apps, and applications
These views serve different purposes:
- Marketplace answers “What can I connect?”
- Installed Apps answers “What is connected for me or my account?”
- Applications answers “What integrations do I own or administer?”
Do not interpret marketplace visibility as authorization. Review requested permissions and complete the connection flow before expecting access.
Ownership and access
Application management requires application or administrator authority for the requested action. Being a workspace owner does not necessarily make a user an application administrator, and installing an app does not grant ownership of its application record.
Application access can be public, invite-only, approval-required, or restricted to selected workspaces where configured. Effective access also depends on the user's account and workspace permissions.
Released interfaces
Application records are exposed through:
- dashboard application pages;
- released REST application routes;
- MCP
manage-applicationfor list, create, and update operations available to the caller.
Inspect GET /api/docs and MCP tools/list at runtime. Dashboard, REST, and MCP shapes are related but not interchangeable.
Application lifecycle
A safe lifecycle is:
design → register as draft → configure → test → review permissions → publish as beta/active → monitor → deprecate → archiveStatus changes affect visibility and user expectations. Do not move an incomplete app to beta or active merely to test configuration.
Security baseline
- Use exact HTTPS URLs.
- Select only necessary grant types and scopes.
- Keep secrets and refresh tokens server-side.
- Treat Device Codes as short-lived credentials.
- Use separate environments and credentials.
- Review application admins regularly.
- Remove or archive unused integrations.
- Never publish credentials in app descriptions or fragments.