unitysvc
MarketPricingDocsAbout

unitysvc

MarketPricingDocsAbout
One account · four gateways

Use digital services through one account.

Discover and combine services across API, SMTP, S3, and MCP. One key, one wallet, and one place to manage access, usage, and spend.

Explore services

Sign in with Google or GitHub · Pay only for what you use.

Have a service to sell? Bring the endpoint and price. UnitySVC handles discovery, access, delivery, metering, and payment.

One API key
active
svcpass_••••••••••••••••
Drop-in compatibleOpenAI- and Anthropic-compatible · 20+ providersHow the platform key works
4 gateways
One substrate
Drop-in
OpenAI-compatible
One key
One wallet, one bill
Usage-based
Pay per call
For customers

Use services through one front door

One account across services

One key, one wallet, and one usage history across providers and protocols.

Services that work together

Route, chain, and fan out requests across services without maintaining separate integrations.

Explore chainsExplore broadcasts

More capability in every call

Add translation, failover, retries, caching, mirroring, and logging without rebuilding those capabilities in every application. Primitives are free — you pay only the underlying call.

Explore primitives

Clear costs and control

See usage and spend in one place, and pay each service's published rate — the price on the listing is the price you are billed.

For sellers

Build the service. We handle the marketplace around it.

Get discovered

List once so customers can find, evaluate, and enroll in your service through the marketplace.

Reduce the cost of serving each customer

UnitySVC meters usage, collects payment, and consolidates your earnings into platform payouts.

Skip the delivery plumbing

Use the platform's protocol front doors, authentication, routing, enrollment, and metering instead of building them around every service.

Keep customers away from your infrastructure

Customers authenticate with UnitySVC rather than receiving your upstream credentials or endpoint details.

Popular on UnitySVC

A taste of the catalog

See all services

No featured services yet — browse the full catalog.

Browse marketplace
What one key lets you do

One key in. Any gateway out.

One key, one URL grammar — four gateways behind it. The AI gateway accepts OpenAI or Anthropic and translates either way; the API gateway composes routing in the path; the SMTP gateway bridges inbound mail to SMTP and HTTP; and two gateways can chain to fan one message out to Discord, ntfy and Slack at once.

SMTPto:you@svc…→ forward → SMTP relay + HTTPS webhook1 gateway
forward targets
Inbound · SMTPEmailto: you@svc…
SMTP gateway

Receives mail over SMTP, forwards out

SMTPrelay to an upstream MTA
HTTPPOST to a webhook
SMTP relayRelay
HTTPS webhookWebhook
SMTPSMTPHTTP
Inbound · SMTP
Email · to: you@svc…
SMTP gateway
SMTP relay to an upstream MTAHTTP POST to a webhook
forward targets
SMTP relaySMTPHTTPS webhookHTTP

Give a workflow an email entry point. Mail to its assigned UnitySVC address is relayed on to an upstream SMTP service and POSTed to your webhook at the same time.

Read about the SMTP gateway
The primitive set

Thirteen verbs, one character each

Compose them in the URL. The primitive is free; you pay only for the underlying call.

See the full primitive reference
Route
/g/group
/a/alias
/e/enrolment
/p/platform
Fan out
/b/broadcast
/c/chain
Resilience
/f/failover
/t/mirror
/r/retry
Observe
/m/cache
/l/log
Schedule
/s/schedule
/d/defer
Get started

A one-line config change

Keep your existing OpenAI client. Set UNITYSVC_API_KEY, point the base URL at our gateway, and call providers on the platform.

Read the quickstart
app.py
from openai import OpenAI

client = OpenAI(
    base_url="https://api.svcpass.com/g/llm/v1",
    api_key=os.environ["UNITYSVC_API_KEY"],
)

# same client, any provider
client.chat.completions.create(model="anthropic/claude-sonnet")

Ready to get started?

One account unlocks the whole catalog. No contracts, no per-provider setup — pay only when you call a service.

Browse marketplace
unitysvc

Unified Digital Service Provider.

PRODUCT

  • Pricing

RESOURCES

  • Docs
  • Support
  • Blog

COMPANY

  • About

LEGAL

  • Terms of Use
  • Privacy Policy
© 2026 UnitySVC

Privacy preferences

Choose whether UnitySVC can use analytics

We use necessary storage for sign-in, security, and preferences. Analytics is optional and stays off unless you accept it. Read the Privacy Policy.

/

Chain

Endpoint — /c/NAME/...

Runs an ordered list of steps against different targets, one at a time, where each step decides what happens next based on whether it succeeded (a 2xx response) or failed. Use it when one call's outcome should pick the next — try a cheap model first and fall through to a stronger one, or run a validation call and only proceed if it passes.

Description

A chain is your own named sequence of steps, reached at /c/<name>/.... The gateway dispatches steps in order; after each one it reads the step's on_success (on a 2xx) or on_failure action to decide whether to stop, move to the next step, or jump to a named step. When the chain stops, the terminating step's response is returned verbatim — same status, body, and content type — so the chain is transparent to your client. Any path after the name (/c/llm/chat/completions) is appended to every step's target.

A chain does two things as it walks the steps: conditional re-dispatch of the original request, and chaining of one step's response into the next. Each step's action — on_success when it returns 2xx, on_failure otherwise — selects which:

  • stop — end the chain and return this step's response.
  • relay — send the original request to the next step.
  • relay_to:<name> — send the original request to a named step.
  • pipe — send this step's response to the next step.
  • pipe_to:<name> — send this step's response to a named step.

The verb names the payload and pairs with its _to:<name> variant: relay / relay_to re-dispatch the same request (decision/failover logic — "try A, on failure fall through to B"), while pipe / pipe_to forward the response (a real pipeline — generate → validate → transform). By default a chain relays; it is not a data pipeline unless you use pipe / pipe_to. The full action set is available on both on_success and on_failure.

Unlike broadcast, which fans one call out to many targets at once, a chain is strictly sequential and branch-aware. It composes with the request primitives: a step's target_path can itself be an alias, a service group, or a wrapped path.

Rules

FieldRule
nameLowercase alphanumeric with hyphens/underscores; unique within your scope; max 64 chars.
StepsOrdered list, at most 10 per chain; unique names; each runs in sort_order sequence.
target_pathThe path a step calls (a service, alias, group, or wrapped path).
on_successAction when the step returns 2xx. Default stop.
on_failureAction when the step returns non-2xx (or times out). Default relay.
ActionsSame set on either branch: stop (return this step's response), relay (next step, same request), relay_to:<step_name> (jump, same request), pipe (next step, fed this step's response), or pipe_to:<step_name> (jump, fed this step's response).
DirectionForward only. A relay_to / pipe_to target must be a step later in the sequence — chains never jump backward, so there are no loops, graphs, or trees, just a forward sequence that always terminates.
timeout_msPer-step timeout; falls back to the chain's default_timeout_ms (10000 ms).

Because jumps only move forward, a chain always terminates. The primitive is free — you pay only for each step's underlying call. Responses carry X-UnitySVC-Chain-Step (the step that terminated) and X-UnitySVC-Chain-Steps-Run.

Manage — Dashboard: Chains (/chains). API: POST/GET/PATCH/DELETE /chains, plus /chains/{id}/steps to edit steps and /chains/{id}/import-from-group to seed steps from one of your service groups. Chains are personal by default; pass ?shared=true to create a team-wide one — like aliases, only team owners and billing managers may write shared chains.

Examples

text
# Try the cheap model; on any failure fall through to the strong one.
step "cheap"  target=/a/fast-llm   on_success=stop      on_failure=relay
step "strong" target=/a/strong-llm on_success=stop      on_failure=stop

POST /c/llm/chat/completions   → runs "cheap", returns it if 2xx,
                                 otherwise runs "strong" and returns that.
text
# Real pipeline: generate, then feed the result to a validator.
step "generate" target=/a/writer-llm  on_success=pipe  on_failure=stop
step "validate" target=/a/checker     on_success=stop  on_failure=stop

POST /c/draft/...   → runs "generate"; on 2xx its response BODY becomes the
                      request to "validate", whose response is returned.

Related topics

  • Broadcast — fan one call out to many targets in parallel, instead of in sequence
  • Failover — automatic backup on 5xx/429/timeout when you don't need per-step branching
  • Retry — re-attempt the same target on transient failures
  • Request Primitives — how /c/ composes with the other URL prefixes
  • Alias — a stable name a chain step can target