On CP4BA the workflow endpoints sit behind the Zen front door (IAM). A client needs a Zen identity, and for the workflow APIs additionally the CSRF token. Three working options:
1. Zen API key (recommended for technical users) - generate the key in the Cloud Pak dashboard (profile > API key) for a service user, then send Authorization: ZenApiKey base64(user:apikey):
KEY=$(echo -n "svc-workflow:AbCd...apikey" | base64 -w0)
# CSRF token (needed for every non-GET on /rest/bpm/wle/v1 and for every call on /bpm and /ops)
TOKEN=$(curl -sk -X POST "https://cpd-cp4ba.apps.cluster.example.com/baw/<instance>/bpm/system/login" \
-H "Authorization: ZenApiKey $KEY" -H "Content-Type: application/json" \
-d '{"refresh_groups": false, "requested_lifetime": 7200}' | jq -r .csrf_token)
curl -sk "https://cpd-cp4ba.apps.cluster.example.com/baw/<instance>/rest/bpm/wle/v1/exposed/process" \
-H "Authorization: ZenApiKey $KEY" -H "BPMCSRFToken: $TOKEN" 2. Bearer token from IAM - exchange the user's credentials (or the API key) for a JWT at https://cpd-route/v1/preauth/validateAuth (header username + password / api_key) and send Authorization: Bearer <accessToken>; tokens expire (default 12 h), keys do not.
3. Browser clients (coach views, custom UIs on the same origin) - the Zen session cookie authenticates; you only add the BPMCSRFToken obtained from POST /bpm/system/login.
Find the base URL: oc get icp4acluster -o jsonpath='{.status.endpoints}' lists the workflow server / center routes (Zen paths look like https://cpd-<ns>.apps.../baw/<name>/; older releases exposed a direct icp4adeploy-...-baw-server route). The technical user must be onboarded in Zen (Access control) with a role that includes the workflow capability, and have the BAW-side rights (teams, tw_admins for admin APIs) like any other user.
References