Skip to main content

Dependencies and Connections

Most useful packs do not live alone.

They depend on:

  • other packs
  • host services
  • external APIs
  • workspace-specific connection state

Those dependencies need to be declared, not guessed.

Pack dependencies​

If your pack calls another pack’s tools, declare that dependency up front.

That gives Worka a way to:

  • validate the composition
  • govern the relationship
  • reject calls that bypass the declared model

Pack-to-pack composition is powerful, but it should remain explicit.

External connections​

When your pack needs credentials or account context, use the connection model rather than embedding secrets in business logic.

In practice that means:

  • declare the connection provider in the manifest
  • rely on the host to resolve the active workspace connection
  • use host-approved templates or references where needed

This is how packs stay reusable across workspaces without learning to manage raw credentials themselves.

Broker template expansion​

For brokered HTTP requests, Worka supports a narrow template surface such as:

  • {{connection.access_token}}
  • {{connection.refresh_token}}
  • {{connection.provider}}
  • {{connection.metadata.<field>}}

The pack passes those templates in string fields. The host resolves them from the active workspace connection before the request is sent.

That keeps Treasury-backed secret material inside the platform boundary while still letting the pack do real work.