Put your workflow to work

1. Test the decision first

Run a normal task and an exception in the editor. Check the route, final result, budget and any tools. Sim demonstrates the design; a successful Sim run does not prove that a Live integration works. Review the Eval cases and test with Live models before connecting real events.

2. Save, publish and create a Run URL

Sign in to save your graph. Connect an Ollama Cloud key saved to your account, or use eligible hosted credits. Open Run from events in the editor, review the draft, publish it, and create a URL. Copy it into your automation service’s secret storage.

Each workflow has its own Run URL and numbered published versions. Later draft edits do not affect events until you publish again. Existing Run URLs keep a snapshot of the graph saved when versioning was introduced. Requests already running keep the version they started with.

3. Choose what starts a run

If the source cannot customise a webhook’s JSON body, put an automation step or server between it and Nodagentry to convert the event to a task.

4. Configure the HTTP request

Method

POST

URL

Your secret Run URL

Content-Type

application/json

Idempotency-Key

One stable key per event (up to 120 characters)

JSON body

{"task":"Text describing the work to do"}

Send a task of up to 8,000 characters. Never put the Run URL in a public webpage or shared screenshot. It authorises execution without a separate sign-in.

curl --request POST "$NODAGENTRY_RUN_URL"   --header 'Content-Type: application/json'   --header 'Idempotency-Key: support:ticket-123:created'   --data '{"task":"Ticket 123: customer reports a duplicate charge. Draft a response."}'

5. Use the response

Wait for the response and check success and status. HTTP 200 alone does not mean the workflow succeeded. The response includes headline, body, path, costUsd and latencyMs. Sending a result to chat, email or a ticket is a separate action your caller must perform; a page card does not itself page anyone.

Configure the caller’s timeout for a potentially long model run. If it times out, reuse the same event key and task rather than starting a second execution.

6. Handle retries deliberately

• 202: this key is still running. Wait for Retry-After, then resend the same request.
• 429: another run is in progress. Queue the event and retry after Retry-After; avoid an immediate retry loop.
• 200 with reused: the saved result is returned without running again.
• 422: the published workflow contains a human gate and cannot execute unattended.
• 402: check hosted credits or the account’s Ollama Cloud key.
• 409: inspect the error. The workflow may not be published, the key may belong to another task, or the previous run failed or expired. Check possible external effects before deliberately using a new key.
• 500 or lost connection: retry with the same key to discover the recorded outcome. A failed record will return 409; do not automatically generate a fresh key.

Rotating the Run URL stops new requests using the old URL. Update every connected caller. Rotation does not cancel work already in progress.

7. Inspect recent event runs

Open Run from events and refresh Recent event runs. It shows the latest 20 requests for this workflow, the published version, task, outcome, duration, result and available step details. Cost is an estimate, not a provider invoice or recorded credit debit. Expired runs have an unknown outcome: check external effects before deliberately retrying. Legacy records may have no version or step details.