Webhook events are normalized.
Provider events are checked for signature status, idempotency, provider reference, settlement ID, route ID, and funding amount.
Provider Activation Binding · funded work rail
Provider confirmations become executable OS credits.
Provider Activation Binding connects a verified settlement event to runtime records: webhook verification, credit funding, settlement receipt issuance, run eligibility, result contract state, callback routing, and ledger-backed attestation.
Agentic rails for complex work.Provider events enter one activation rail so funded credits, receipts, runs, and callbacks stay aligned.
What this rail does
It turns settlement confirmation into operating state.
The provider abstraction defines the route. Runtime Data Binding defines where the records live. Provider Activation Binding is the handoff where a verified provider event funds credits and makes the run eligible.
Credits are written to the ledger.
A verified confirmation creates a credit funding event tied to the agent, task token, credit account, entitlement, and settlement receipt.
The task becomes run-eligible.
The run contract, quote, provider route, and credit entitlement can advance into queue and operating-tool execution.
The proof trail stays whole.
Settlement receipt, usage receipt, result contract, callback, task ledger, and attestation all point back to the activation binding.
Runtime activation sequence
The provider event writes into the OS spine.
The activation binding keeps provider-specific settlement rails modular while giving Wever Labs one way to fund work, issue receipts, and move a task into execution.
provider_event
→ webhook_verification
→ provider_confirmation
→ credit_funding_event
→ settlement_receipt
→ run_eligibility
→ result_contractMachine-readable activation
Agents and builders can inspect the funding handoff.
The activation rail exposes schemas, examples, API routes, SQL scaffold, and function stubs so provider confirmations can be carried into durable OS state.
Next operating step
Run the full loop with provider-funded credits.
TokenOps, FinanceOps, and EnergyOps can use the same activation rail: provider confirmation funds the work, the OS runs the task, and the result returns with proof.