The present, unwrapped
One account.
One wallet.Everything else follows.
Most products are built from a dozen vendors, a dozen keys, a dozen invoices and a dozen places where the customer's data now lives. castomAPI is the argument that it can be one.
One key, not a keyring
The Engine exposes 706 operations in 48 groups, and every one of them takes the same x-api-key header. There is no per-endpoint enablement, no plan gating a group, no second product to buy for the integrations. You verify a VAT number, convert a colour and read a Shopify order with the same string, and the ledger shows the three calls in a row.
One wallet, debited only on success
Every metered call names its cost in its own description. The debit happens after the response is sent and only when the status is under 400. A validation error, a refused upstream, a timeout, a miss — none of them cost anything. The wallet may run a bounded overdraft rather than refusing a request mid-flight; it nets out against the next top-up.
A thousand free tokens, every month, for everyone
Every account is topped back up to 1000 tokens a month — topped up to, not by, so nothing stockpiles and a paid balance is never reduced. Most of the catalogue costs one token a call. A weekend script, a prototype, a small internal tool never needs a card.
30 integrations, each through the customer's own account
The integrations do not use castomAPI's credentials on your customers' behalf. Each connects through OAuth — or the platform's own application password — to the end user's account, so the rate limit is theirs, the audit trail is theirs, and revoking consent on their side ends it on ours. Tokens are stored encrypted and refreshed on demand; a project sees only its own connections.
When the catalogue is not enough, write the endpoint
Upload JavaScript that defines main(req) and it gets a URL at /c/your-slug. It runs in an isolated V8 per request with two seconds of CPU, 128 MB, and a fetch that refuses private addresses and re-validates every redirect. It is billed from the same wallet, and it can call the rest of the catalogue from inside.
Accounts, billing, payments and bookings are services
A product built on the platform does not write sign-in, does not write billing, does not write checkout. Auth issues the identity every service recognises. Billing turns a Stripe subscription into an entitlement the product reads. Pay charges a customer on a seller's behalf. Book holds a slot. DB stores the product's documents. Live carries presence between people. The product is the part that is yours.
Two audiences, one account
If you build products, this is one bill and one dependency. If you use dash-b, castomo, castomUI, castomFlow, clickSomo, FABLS or castoMIND, your account is already here: every live widget, workflow step and generated page draws from the same wallet, and you can call the API yourself with the same key. Nobody has to choose.
What it is not
It is not certified by anyone yet, it has no published uptime figure, and it does not pretend to. The status page records what every service answered when this site was built, with the date. The security page says what is sandboxed, what is encrypted and what is never stored. The numbers on the stats page are counted from the specification, not estimated.