Capabilities define which payment methods your proxy accepts. Routes let you override pricing for specific API paths.
Capabilities (global defaults)#
A capability represents a payment method available to your account. Each capability combines:| Setting | Example | Description |
|---|
| Network | Solana, Base, SKALE | The blockchain network |
| Currency | USDC | The token used for payment |
| Scheme | Exact (x402) | The payment protocol |
| Wallet address | 7xKXtg... | Where you receive payments |
| Default price | 0.10 USDC | How much to charge |
| Usage model | Pay per request | How access is consumed |
| Usage limit | 100 requests | How much access each payment buys |
Enabling a capability#
1.
Go to Capabilities in the Kobaru Console
3.
Select the network, currency, and scheme combination
Configuring a capability#
After enabling, configure the required fields:1.
Click the edit icon on the capability row
2.
Set your wallet address (where payments are sent)
3.
Set the default price (in USDC)
4.
Choose a usage model (pay_per_request or pay_per_time)
5.
Set the usage limit (number of requests or seconds)
All four fields are required. The proxy won't process traffic until at least one capability is fully configured.Multiple capabilities#
You can enable multiple capabilities to accept payments on different networks. When a client requests your API, they receive all available payment options and choose which one to use.
Usage models#
Pay-per-request#
Clients purchase a bundle of requests. Each successful API call consumes one request from their balance.1.
Client pays and receives N requests
2.
Each successful request decrements the counter
3.
When the counter reaches 0, access is denied
Usage credits: If your backend returns certain errors, the request is not counted against the usage limit:| Status code | Counted against usage? | Reason |
|---|
| 200-299 | Yes | Successful response |
| 400, 404, 422 | Yes | Client error |
| 401, 403, 429 | No | Upstream issue (credit restored) |
| 500-599 | No | Server error (credit restored) |
"Credit restored" means the usage counter is incremented back. No blockchain transaction is reversed.Pay-per-time#
Clients purchase unlimited access for a duration. The clock starts on first use.1.
Client pays and receives a time window (e.g., 1 hour)
2.
Timer starts on the first request
3.
Unlimited requests allowed until the timer expires
4.
After expiration, access is denied
No refunds: Time-based access is not refundable. Once the timer starts, time elapses regardless of usage or errors.Choosing a model#
| Use pay-per-request when | Use pay-per-time when |
|---|
| Usage varies between clients | Clients need high-frequency access |
| You want proportional billing | Usage is predictable |
| Clients make occasional requests | You want to reduce payment friction |
| You want refunds for errors | Simplicity is more important |
Routes (path-specific overrides)#
Routes let you set different pricing for specific API paths. Without routes, all paths use the capability's default pricing.Creating a route#
1.
Go to Routes in the Kobaru Console
3.
Select the service this route applies to
4.
Enter the path pattern (e.g., /premium/*, /free, /historical)
5.
Override the price, usage model, or usage limit
How route matching works#
When a request arrives, the gateway:1.
Checks if the request path matches any route pattern
2.
If a match is found, uses the route's pricing overrides
3.
If no match is found, uses the capability's default pricing
Example configuration#
Service: weather-service
Capability default: 0.10 USDC per 100 requests
Routes:
/premium/* --> 0.50 USDC per 50 requests
/free/* --> 0.01 USDC per 10 requests
/historical --> 0.20 USDC per 200 requests
A request to /premium/forecast uses the premium pricing. A request to /current uses the default capability pricing.
Next steps#
Modified at 2026-02-10 21:52:10