Workflow Targets

Overview

A workflow target tells Robots Center where to send a test or replay request. It describes your workflow's HTTP endpoint, environment, timeout, and authentication settings; registering one does not run the workflow. Evaluations and replays later use this destination to execute a selected version with a specific input and configuration.

Targets and versions are separate

The target stores destination, auth mode, environment, timeout, and metadata. Its response includes version summaries, but the public machine API has no create, update, archive, or baseline route for workflow versions; operators manage those in the console.

Secrets are references

Use auth_type none, bearer, or api_key_header. Auth configuration carries secret_ref_id and, for API-key mode, the header name; list/create responses sanitize auth configuration and never expose secret material.

Creation validation is not execution success

The stored base URL must be absolute HTTP(S), and timeout is 1 through 120000 ms. Actual invocation applies outbound URL policy, production HTTPS/private-network protections, no redirects, and no automatic HTTP retry, so connectivity can still fail later.

How it works

1. Prepare destination and secret

   Deploy a public HTTPS handler and create any managed secret through the operator controls. Decide whether the remote service expects a bearer value or a named API-key header.

2. Create a clearly labelled target

   POST name, optional URL-safe slug, base URL, auth configuration, environment, and bounded response timeout. Keep environment and metadata descriptive rather than embedding credentials.

3. Attach evaluation assets

   Use the returned target ID when creating eval suites or replay requests. Manage versions and test cases in the operator console, then test with a deliberate eval run.

Examples

These examples are illustrative. Replace the sample values with your own. Keep credentials in environment variables or a secret manager, never in client-side code.

export AGENTOPS_BASE_URL="https://robotscenter.net"
export AGENT_TOKEN="machine_token_with_workflow_target_write"
export MANAGED_SECRET_ID="1ba09a28-acde-45ff-9026-877df82421cb"

jq -n --arg secret "$MANAGED_SECRET_ID" \
  '{name: "Example checkout workflow", slug: "example-checkout", base_url: "https://workflow.example.com/v1/run", auth_type: "bearer", auth_config: {secret_ref_id: $secret}, environment: "production", timeout_ms: 30000, metadata: {team: "payments"}}' |
  curl --fail-with-body --silent --show-error \
    -X POST -H 'content-type: application/json' \
    -H "Authorization: Bearer $AGENT_TOKEN" \
    --data-binary @- "$AGENTOPS_BASE_URL/api/v1/workflow_targets" | jq .

Troubleshooting

Creation rejects the URL or slug

Use an absolute HTTP(S) URL no longer than 255 characters and a lowercase slug containing only letters, digits, and hyphens. Duplicate slugs conflict within a workspace.

Evals cannot reach a stored target

Creation does not perform the call. Check DNS, production HTTPS, private/reserved-address policy, the managed secret, the remote handler contract, and the response timeout. Redirects and automatic request retry are disabled.

A secret value is missing from the response

That is intentional. Target reads expose only safe auth configuration fields; retrieve or rotate secret material through the authorized operator secret workflow.

Endpoint reference

Ready to integrate? Open an endpoint for its required permissions, request fields, response format, and status codes. The examples above explain the workflow; these details define each individual request.