PriorAuthdocs

IBM watsonx Orchestrate

Orchestrate imports an OpenAPI specification and turns each operation into a skill. This platform generates that spec from the same registry that produced the A2A card.

#Getting the spec

bash
curl -H "authorization: Bearer $TOKEN" https://app.authprior.com/api/orchestrate > priorauth.json

Import it in Orchestrate as an OpenAPI skill set. Each registered agent becomes one operation, described in outcome terms rather than as a sequence of tool calls.

#Two things to configure on the Orchestrate side

  1. A long-running pattern
    Operations return 202 with a task id when work is held at the release gate. The skill has to poll rather than treat a non-200 as a failure - the default retry behaviour will create duplicate tasks.
  2. The connection identity
    Orchestrate authenticates as a channel principal bound to specific practices. It is not a superuser, and a practice that has not authorised the channel is unreachable through it.

#What Orchestrate should not be asked to do

  • Approve or release anything. There is no operation for it.
  • Enumerate practices. The spec exposes no listing.
  • Poll faster than the payer moves. Prior authorization is measured in days.
One registry, three surfaces
The console, the A2A card and the Orchestrate spec are all clients of the same registry. Adding a tool makes it appear in all three; re-gating one changes all three. None of them can describe a policy the gateway does not enforce.