Skip to main content
Skill installation, runtime setup, credentials, and channels are operational resources. They are separate from the Agent configuration’s authored skills instructions.

Install and verify a skill

Use this sequence under /api/v2/computer/accounts/{targetAccountId}:
  1. Read GET /skills/catalog, the selected /skills/catalog/{skillSlug}, and /skills/state.
  2. Install the exact catalog slug with POST /skills/install.
  3. Verify with POST /skills/{skillSlug}/verify.
  4. Process pending requiredActions by ascending order only after every ID in dependsOn is complete.
  5. Verify after each setup or authorization change.
  6. Finish only when verification reports setup complete and the catalog detail reports the skill ready.
If asynchronous verification returns 202, poll the verification job exposed by the catalog detail, then run synchronous verification to read the current result.

Complete setup actions

  • For editable values, read /skills/{skillSlug}/setup-values?storageKey=... before writing /setup-state.
  • For sensitive values, use the managed-secret route indicated by the setup action. Never store a secret in setup-state or a workspace file.
  • For uploads, use the exact declared workspace path and verify the file afterward.
  • For authorization or device login, start /skills/{skillSlug}/auth/{actionId}/start, present the returned user action, and poll the matching status endpoint until terminal.
  • For manual confirmation, wait for the user to complete the external step.
Do not infer that a browser page opening or device code appearing means authorization succeeded.

Manage declared credentials

Use the /secrets routes to list configured IDs, save or update values, check deployment, reapply drifted values, and delete values with explicit intent. Agent-scoped credentials belong to the selected Agent. An organization value may be inherited only when no Agent value with the same ID exists. List and check responses prove whether a value is configured without returning it. Before deleting a credential, inspect the skills, helpers, and connections that declare it. Verify those capabilities again after any credential change.

Configure one Agent-specific channel

Read /channels/catalog and /channels/status before changing a channel. Submit only the catalog’s public connection, access, and enabled fields to /channels/configure. The account in the route owns the connection and receives its inbound messages. Do not add a second account selector to the body. After configuration:
  1. Complete a web or device-login flow when required.
  2. Wait for that flow to reach a terminal state.
  3. Probe channel status.
  4. Test an allowed sender or channel.
  5. Test the intended mention policy and one denied location.
Use narrow direct-message and group allowlists. Starting a login flow or saving a token is not proof that inbound routing works.
For complete request patterns and verification rules, use the Vida API Skill.