Skip to main content
Offload moves a case to INPUT_NEEDED when the worker decides it cannot continue safely without a human answer from your application.

​
What You Receive

If clientWebhookUrl is configured, you receive case.input_needed with:
  • inputRequest
  • inputRequestId
  • inputRequestStatus
  • inputRequestedAt
Example:
You can also fetch the same active question from GET /cases/{id} while the request is still present on the case.

​
Resume The Case

Submit the answer with the same inputRequestId:
Successful acceptance:

​
What 202 Accepted Means

The current implementation performs two steps:
  1. enqueue an internal INPUT_PROVIDED event
  2. immediately update inputRequestStatus to RESOLVED
That means:
  • your answer was accepted for async processing
  • the case may still briefly read as INPUT_NEEDED
  • the worker has not necessarily replied to the counterparty yet

​
When The API Returns 409

POST /cases/{id}/input returns 409 when:
  • the case is not currently INPUT_NEEDED
  • the active request is no longer PENDING
  • the provided inputRequestId is stale or mismatched
  • Persist inputRequestId from the webhook.
  • Show inputRequest to the human or system that can answer it.
  • Keep providedContext direct and decision-oriented.
  • Treat 202 as queued work, not a final state transition.
  • Watch for the next webhook or poll the case to confirm the new state.

​
What Happens Next

After the worker processes your answer, it can:
  • send the next reply and return to RUNNING
  • complete the case
  • fail the case
  • ask for more input again
When the answer is added, the worker appends it into goal.knowledge.additionalHumanContext before re-evaluating the case.