Agent-readable docs index: /llms.txt. Full docs in one file: /llms-full.txt. Download /docs.zip to grep all markdown files locally.

Apps and credentials

Connecting an Organization connection requires the owner or admin role; members connect only their own Personal connections. Each Stackyapper app uses one of two connection ownership models. In Apps, they are labeled Shared (Organization connection) and Per-user (Personal connection).

Organization connections

An Organization connection is shared inside one workspace. Admins typically use this model for PSA, RMM, security, and documentation systems that provide a workspace-level API account.

Personal connections

A Personal connection belongs to one Stackyapper user. Apps that represent an individual account ask each user to complete their own authorization. An admin enabling the app does not create that personal authorization for everyone.

Availability and rollout state

Some apps are available to every workspace; others require approval before a workspace can use them. Separately, open an app and expand Integration evidence for its Alpha, Beta, or Certified testing stage. Beta apps remain visible while their provider coverage is being verified, and a Certified app can still require approval.

Connect an organization app

  1. Create or select a provider identity limited to the intended tenant, role, and scopes.
  2. Select the intended Stackyapper workspace.
  3. Open Apps and review the app's status and whether it is Shared or Per-user.
  4. Enter or authorize the provider credential for that workspace's provider tenant.
  5. Save the connection.
  6. Run the smallest available read and verify it in Audit.
Do not test a new credential with a write operation. Verify with the smallest available read first.

Rotate a shared credential

  1. Create the replacement credential in the provider, preserving the same provider tenant and least-privilege scope.
  2. Update the app in Stackyapper.
  3. Run a small read and verify it in Audit.
  4. Revoke the old provider credential.

Build an app with your agent

Workspace owners and admins can build an app from an API definition and share its tools with the team. Custom connectors are Beta.
  1. Open Apps → Add app → Build with your agent.
  2. Copy the instructions for your agent. Give it the provider's API documentation and the tasks you want to support.
  3. Ask the agent to prepare an OpenAPI JSON definition for those tasks. Keep API keys, tokens and client secrets out of the definition and the conversation.
  4. Preview the definition. Review the available tools and fix any calls shown as unsupported before saving.
  5. Save the app, then follow its connection and read-only verification steps.
  6. Open Tools & access to assign calls to people or groups.
The app appears in your workspace's private apps and uses the same connection, tool classification and access controls as other apps. Teammates use their existing Stackyapper MCP connection to find and run the calls they can access. Saving a definition does not connect an account or grant the team access.
Personal OAuth accounts remain personal: each teammate authorizes their own account. A supported Organization connection can be shared using the existing workspace access controls. OAuth setup may require your own provider client registration.
The builder supports API definitions that Stackyapper can validate. It does not host arbitrary server code. Calls with unsupported authentication, response fields or list limits stay unavailable until their definition is corrected. Building an app does not make it Certified.

Update a private app definition

Owners and admins can update a private app imported from an OpenAPI definition.
  1. Open the app in Apps, then select Definition.
  2. Load the updated JSON or YAML file and select Preview update. Previewing keeps the current app running.
  3. Review the tool changes and the connection and access steps shown. Unsupported calls are listed with reasons and stay excluded. Compatible calls can be updated together without reviewing each call yourself.
  4. For a compatible update, select Apply and verify. Stackyapper reuses the saved credentials, runs the displayed read-only check, and reactivates the app if the check passes. Other updates show the steps needed after applying.
  5. Review Tools & access. Unchanged access can carry forward; new and changed tools need access assigned. Choose your account, a member, or a group to assign the available calls.
When an owner or admin opens Apps, Stackyapper also refreshes compatible tools left unavailable in an already active private app. Full access carries forward across this refresh. Individual tool grants, refusals, and expired access keep their limits. Calls missing required field definitions or list limits remain unavailable until the app definition is corrected.
Applying pauses calls until the updated app is verified and activated. If a check fails, the definition stays saved. Follow the displayed next step, then use Continue update when available. Changes to authentication require reconnecting. Older apps with saved platform restrictions may need a supported migration before updating; the current definition stays in place. If the definition has no compatible calls or no supported read-only connection check, it cannot be applied. The current app keeps running while you correct the definition.
Request bodies can use local schema references to declared fields. Stackyapper accepts only those fields and keeps their validation rules. Compatible request fields can accept a number or a string, including null when declared. Response alternatives can include a value or null; unsupported alternatives remain excluded. List calls still need declared limits.
Stackyapper classifies available calls automatically using the definition and its request and response fields. Sensitivity labels describe what a call may handle. They do not report the contents of a response. Approved reads run without an extra confirmation step unless their saved policy requires one; writes and higher-risk calls keep their confirmation safeguards.

Reconnect or disconnect

Reconnect when the provider credential expires, is revoked, or no longer has the required provider scope. Preserve the same provider tenant unless the original connection was incorrect.
Before disconnecting an Organization connection:
  1. Identify users and workflows that depend on it.
  2. Revoke or update related Stackyapper grants.
  3. Disconnect the app.
  4. Revoke the old credential at the provider when appropriate.
  5. Confirm new calls no longer use the connection.

Review credential ownership and scope

Review a connection when its owner changes, a user leaves, the provider changes its permissions, or a workflow no longer needs the same access. For every Organization connection, verify:
  • The provider identity still belongs to the intended tenant.
  • Its provider-side role and scopes are no broader than the current workflows need.
  • The person responsible for rotating or revoking it is still known.
  • The related Stackyapper app and tool grants still match current job duties.
Stackyapper permissions cannot narrow what someone does by signing directly into the provider account. Keep the provider credential itself least-privileged.

App needs attention

Use the status shown on the app in Apps to pick the right fix:
  • Platform setup required: the app is waiting on a Stackyapper-side setup requirement; a new credential does not fix it.
  • Ready to configure: an app without its Organization connection, shown to a user who can configure it.
  • Admin setup required: the same unconnected app, shown to a user who cannot configure it—ask an owner or admin.
  • Your connection required: the app uses Personal connections and you have not authorized your own account yet.
  • Needs attention: the existing connection is unhealthy; review the displayed error and reconnect if it is credential-related.
  • Configured: the connection is saved but has not yet completed a successful call.
  • Connected: the connection is saved, healthy, and has completed at least one successful call.
Reconnect only when the issue is credential-related. A provider outage, platform-setup requirement, or pending approval is not fixed by repeatedly replacing a valid user credential.
Provider credentials let Stackyapper reach the provider; Stackyapper policy still decides which tools a user or AI client can discover and run.