Getting started
Ship your first commercial API product with Farther Shore.
Farther Shore helps API builders turn an upstream service into a product people can discover, subscribe to, call with API keys, and pay for.
You bring the API. Farther Shore provides the product model, developer portal, API keys, billing strategy, usage metering, and gateway enforcement layer around it.
What you can build
Use Farther Shore when you want to:
- sell access to an API without building a billing system first
- publish a developer portal for subscribers
- issue and revoke subscriber API keys
- enforce plan limits at the edge
- meter usage for billing, analytics, and operations
- support subscription, usage, overage, pay-as-you-go, or prepaid credit models
- keep the request path fast by enforcing compiled runtime rules in the gateway
The first product path
Most teams should start with one simple product and one simple meter:
- Create a product in the builder console.
- Choose what the product meters, such as
requests. - Configure the upstream API URL that should receive allowed traffic.
- Pick a billing strategy and create one plan.
- Publish the product.
- Subscribe with a test customer and issue an API key.
- Send a request through the gateway.
- Confirm the request is allowed, forwarded, and metered.
After that path works, add more plans, custom meters, portal content, and launch traffic.
This same path is the fastest way to validate that portal, gateway, metering, and billing behavior are connected end to end.
Prerequisites
Before launching a product, have these ready:
| Requirement | Why it matters |
|---|---|
| Upstream API URL | The gateway forwards allowed requests to this service. |
| Product name and audience | The portal needs clear positioning and labels. |
| Meter choice | Billing and enforcement depend on what usage means. |
| Billing model | Plans must map to how subscribers should pay. |
| Test subscriber | You need a real subscription and API key to validate the path. |
| Product docs | Subscribers need examples and integration instructions. |
Platform surfaces
| Surface | Used by | Purpose |
|---|---|---|
| Builder console | Product owners | Create products, plans, billing, portal settings, and integrations. |
| Developer portal | Subscribers | Discover products, read docs, choose plans, and manage API keys. |
| Gateway | API callers | Authenticate keys, enforce access, forward traffic, and emit usage. |
| Core | Platform control plane | Store products, compile runtime policy, process billing, and publish configuration. |
You usually work in the builder console. Your subscribers usually work in the developer portal. The gateway and core run the product behind the scenes.
What happens when a request is live
When a subscriber calls a live product, the gateway:
- resolves the product from the hostname
- validates the presented API key
- loads the subscriber's compiled plan and entitlement
- checks feature access, limits, credits, and concurrency rules
- forwards allowed traffic to your upstream API
- records usage and sends events back to core
The gateway does not ask core for every request. Core publishes versioned runtime artifacts ahead of time so the request path stays fast.
Next steps
- Read Core concepts for the vocabulary used across the platform.
- Follow Launch a request-counted product for a concrete first build.
- Use Launch checklist before sending production traffic.