Loading...
Loading...
A modern product runs on a dozen outside services. Each one arrives with its own account to create, its own key to guard, its own invoice to reconcile, its own SDK to learn. The friction was never the service. It was the integration tax stacked around every one of them.
Each service ships its own credential to create, store, rotate, and eventually leak. The pile only grows.
Separate invoices, separate payment methods, separate terms. Finance reconciles a dozen line items for one product.
Integrate once to start. Re-integrate to switch. Re-integrate again to add a second option in parallel.
Usage, spend, and latency scattered across a dozen consoles that never agree on what a request cost.
A useful service can still be difficult to sell. Every seller is expected to build discovery, onboarding, authentication, usage metering, billing, and support before the first customer becomes economical.
Our bet: customers should not rebuild an integration for every service, and sellers should not rebuild a marketplace around every endpoint. Collapse both into one platform standing in the middle.
Sellers point us at an endpoint and set a price. Customers reach it through a single key. Neither side ever meets the other — the platform is the only party in between, carrying the work both sides would otherwise have to build.
…and keep their focus on the service. Discovery, billing, delivery, and access happen in the middle.
Privacy by construction, not by policy. Customers authenticate with the platform, never with the seller — so sellers never see who the customer is, and customers never receive the seller's credentials or endpoints. It isn't a setting we offer — it's the shape of the system.
A service might be reached through an HTTP API, an SMTP relay, an S3-compatible client, or an MCP tool connection. Each deserves a proper front door — but the larger advantage comes after entry. Because the gateways share identity, enrollment, routing, metering, billing, and logs, work can move between protocols without becoming four separate integrations.
An email can become an API request and fan out to several services; resulting files can remain available through S3. MCP gives agents another way to discover and use that same service catalog — without another account or billing relationship.
Add a protocol and it inherits authentication, enrollment, routing, metering, and billing on day one. The protocol is a detail. The substrate is the product.
Common behaviors — routing, resilience, composition, scheduling, and observability — should be platform capabilities, not application code. Thirteen one-character verbs compose in the URL ( /m/f/g/llm — cache, fail over, route), and the primitive itself is free: you pay only the underlying call.
We started with the HTTP gateway because that's where the density is. But the plan was always broader: one substrate, many protocols, each added the same honest way — shipped when it's real, not when it's announced.
Status reviewed August 2026
API, SMTP, S3, and MCP gateways on one substrate; the marketplace; one-key enrollment; prepaid wallets and usage-based billing.
Richer groups, pools, and aliases, with better service discovery.
Async, protocol-less task services: human-in-the-loop work, long-running jobs, batch workflows, annotation and review, with task-based payouts. No delivery promises.
One integration should reach a growing catalog — not a growing pile of SDKs. Every feature we add has to earn its place against the cost of the extra concept.
Every service publishes its rate on its listing, and that is what your usage is billed at — per token, per unit, per request. No separate per-call surcharge, and no invoice you could not have predicted from the catalog.
We don't publish a number we can't prove. No vanity metrics, no fabricated totals — if it isn't real yet, we say soon and mean it.
Customers never see infrastructure; sellers never see identities. It isn't a policy we promise — it's the shape of the system, which makes it hard to violate.
HTTP was the first gateway, not the last. Any service reachable over a network deserves the same front door, the same key, and the same bill.
Customers get one place to use services. Sellers get one place to sell them. UnitySVC handles everything required for those services to meet.
Log in with Google or GitHub. Pay only when you use a service.
Questions? Reach us at [email protected]