DOCUMENTATION / SDK QUICK START
Keep your stack.
Add an execution boundary.
An example from the Oorbital SDK documentation. The wrapper governs the action; your application still owns the tool implementation.
1import { RuntimeClient, govern } from "@oorbital/sdk";2import { executeRefund } from "./your-payments";3 4const runtime = new RuntimeClient({5 credential: process.env.OORBITAL_RUNTIME_CREDENTIAL!6});7 8const refund = govern({9 client: runtime,10 proposal: (paymentId: string, amount: number) => ({11 agentId: "agt_...",12 versionId: "agv_...",13 functionKey: "payments.refund",14 action: {15 functionKey: "payments.refund",16 target: { type: "payment", id: paymentId },17 parameters: { amount, currency: "EUR" }18 },19 context: { customerTier: "standard" },20 environment: "sandbox"21 }),22 argumentsFromEffectiveAction: (action, [paymentId]) => [23 paymentId, Number(action.parameters.amount)24 ]25}, executeRefund);26 2701Configure on the server.
Use a scoped Runtime credential. Replace sandbox identifiers and the payment implementation with your own integration. Never put credentials in browser code.
02Use the effective action.
Map the authorised action back into tool arguments. A pending or refused proposal must not execute. A changed action without a mapping must fail closed.
03Test more than the happy path.
Exercise approval, refusal, review, changed actions and an unavailable service. Preserve idempotency, the execution claim and the outcome record.
This website displays the example. It does not execute it or create a live connection.