Skip to main content

Building Service Config Sets

A service configuration set is to services what a workflow configuration is to agents: a named, reusable bundle that turns registered services into concrete, callable requests. A workflow references one service config set to know how to call the outside vendors it needs.

Assigning a service​

Inside a set you add service assignments. For each assigned service you:

  • choose the request method;
  • fill in values for any URL template variables the service defines — required wherever the service's URL has placeholders;
  • add request headers as key/value pairs;
  • optionally configure retries (if you enable retry-on-failure, the retry count must be at least 1).

A service that defines a URL like https://api.abc.com/endpoint/{{VIDEO_ID}} surfaces VIDEO_ID here for you to fill; at runtime the placeholder is replaced with the literal value you supplied. Variable values are literal only — fixed strings, not references to live app data.

A note on secrets​

Don't paste API keys directly into these forms. Header values are stored and passed through as-is — the platform doesn't distinguish a secret from any other value, and it doesn't inject credentials for you. Providing and protecting secrets at call time is the workflow's responsibility, not the configuration's.

Validity and history​

Like workflow configurations, a service config set's validity is derived: disable an underlying service and the set becomes invalid automatically. And editing an assignment affects future runs only — when a workflow executes, Circus writes a snapshot of the service configuration in effect at that moment, so a historical execution always shows the settings that actually applied, not whatever you changed later.