Skip to main content
rebuno.Client creates executions and inspects what they did. Your backend, a script, or an operator uses it, not the agent handler.
base_url is required, from the argument or REBUNO_URL. api_key is optional and sent as Authorization: Bearer ... when present. Client is an async context manager, so it closes its connection pool:
Otherwise call await client.close() when you’re done.

Executions

create and get return an Execution. Poll get or read the event log to watch it progress.

Event log and steps

Read the raw event stream, or the steps it produced:
events is paginated by after_seq: pass the last event_seq you’ve seen. limit defaults to 100.

Approvals

When policy requires approval for a step, the execution blocks and an approval is created. Inspect and resolve them through Client:
Granting an approval lets the kernel re-dispatch. The handler replays its recorded steps and proceeds past the one that was waiting. From the handler’s perspective the blocked call simply returns once approved.

Errors

Failed requests raise typed exceptions: NotFoundError, UnauthorizedError, ForbiddenError, ValidationError, PolicyError, NetworkError, and others, all subclasses of rebuno.RebunoError. See Errors.

Models

Client returns pydantic models. They ignore unknown fields, so kernel additions won’t break you.
  • Execution: id, agent_id, input, status, output, failure_reason. status is an ExecutionStatus, one of pending, running, blocked, completed, failed, cancelled.
  • Step: step_id, execution_id, kind, target, args_hash, occurrence, status, idempotency, args, result, error.
  • Event: execution_id, event_seq, type, payload, occurred_at.
  • Approval: id, step_id, execution_id, status, message, decided_by, rationale.
These live in rebuno.types.