Skip to main content
POST
JavaScript
A tool set that talks to a real API needs a credential. You do not put it in the adapter. You store it as a secret, reference it by name, and Cadenya substitutes it when it makes the call.

The value goes in and never comes out

spec.value is write-only. The create response redacts it, and so does every read:
There is no endpoint that returns a stored value. To change it, update the secret with a new one; you cannot read the old one back to confirm it. Secret names are unique within a tool set. A second secret with the same name is a 409.

Reference it as ${NAME} in the adapter

Adapter headers take ${SECRET_NAME} placeholders. Cadenya resolves them at call time, so the plaintext lives only in the request Cadenya makes, never in your configuration and never in a response.
Verified end to end against a live HTTP adapter: with the header set to Bearer ${ECHO_TOKEN} and the secret stored, the tool call reached the upstream server carrying the resolved value, the literal ${ECHO_TOKEN} never appeared, and the tool call recorded its source:
resolvedSecrets on a tool call gives each secret’s key and the source scope it came from. It never carries the value.

Which scope wins

The same name can exist in three places, resolved narrowest-first: RESOLVED_SECRET_SOURCE_OBJECTIVE beats _TOOLSET beats _WORKSPACE. So a per-user token passed on a single objective overrides a shared service credential for that one run, which is the whole reason objective secrets exist. Store the durable credential here, at the tool set, and let the short-lived one override it per objective.

Store and use secrets

The full precedence story, workspace to objective.

Create a tool set

Where ${SECRET_NAME} goes in an adapter header.

Update a tool set secret

Rotate a value you can never read back.

Create an objective

Objective secrets, which override this one per run.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

workspaceId
string
required

The workspace that owns the tool set.

Example:

"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"

toolSetId
string
required

The tool set that will own this secret. Accepts the canonical ts_… form or the external_id: form.

Example:

"toolset_01HXKD2E5NQM3T9AYWCFNRMN74"

Body

application/json
metadata
object
required

CreateResourceMetadata contains the user-provided fields for creating a workspace-scoped resource. Read-only fields (id, account_id, workspace_id, profile_id, created_at) are excluded since they are set by the server.

spec
object
required

Response

OK

metadata
object
required

Standard metadata for persistent, named resources (e.g., agents, tools, prompts)

spec
object
required
info
object

Tool set secret information