Invoking workflows

Fixed test answers

The cloud service currently uses a fake backend. Successful runs exercise the shared runtime and persistence, but do not contain model predictions. Use local banh run for real Laya inference.

Invoke over HTTP

First deploy a workflow. Set these values using your own provisioned account and invocation key:

export BANH_API_URL=http://127.0.0.1:3000
export BANH_ACCOUNT_ID=acct_...
export BANH_API_KEY=banh_sk_...

Use an API origin without a trailing /v1. The following request invokes the active version of warranty_triage:

curl --fail-with-body --silent --show-error \
  -H "Authorization: Bearer $BANH_API_KEY" \
  --json '{"input":{"claim":{"description":"The upper limb cracked while drawing the bow."}}}' \
  "$BANH_API_URL/v1/accounts/$BANH_ACCOUNT_ID/workflows/warranty_triage/runs"

An authorized developer token also works. Invocation keys cannot deploy workflows or inspect recorded runs.

Inputs and responses

The body is { "input": ... }. Use a JSON string as the input value for a text workflow; use a JSON-compatible value for other supported inputs. Invalid input is rejected before a run is created.

The service captures the active version before executing it. The response includes the run’s status, output, trace, version, and timing. Successful traces identify backend: fake in this revision.

Execution failures persist a failed run and return HTTP 500; deadlines return HTTP 504. Keep the returned run ID for inspection.

CLI cloud invocation is not implemented yet. banh run executes locally and does not call this endpoint.