Farther ShoreDocs
Go to Farther Shore
Getting startedCore conceptsLaunch checklist
ProductsUpstream routingEnvironmentsDeveloper portals
Billing strategiesPlans and limitsSubscribersAPI keys
Gateway enforcementUsage meteringLimits and creditsGateway sharding
Launch a request-counted product15mAdd monthly included usageAdd subscription plus overageCreate a prepaid credits productMeter AI token usageAdd a custom meterIssue and test an API keyDebug a denied requestUpdate product docsPrepare for launch
TroubleshootingGateway response codesMeter namingPlatform docs publishing
Status
Docs/Build Products/Products

Products

Product lifecycle from creation to live gateway traffic.

PreviousLaunch checklistNextUpstream routing

On this page

Product lifecycleCreation flowPublishing flowLive request flowEditing a live productProduct docs

A Farther Shore product is the sellable version of an API. It combines product identity, upstream routing, docs, plans, pricing, subscriber access, and gateway runtime policy.

Product lifecycle

StageWhat happens
DraftYou define the product, meters, plans, portal copy, and upstream settings.
ConfiguredThe product has enough information to compile runtime rules.
PublishedCore publishes product and entitlement artifacts for the gateway.
LiveSubscribers call the product through the gateway with API keys.
OperatedUsage, denied requests, billing, docs, and plans are maintained over time.

Creation flow

The product wizard captures the information needed to create the first runtime shape:

  • product name and display metadata
  • product description and portal labels
  • billing strategy
  • meters and usage units
  • plans, prices, included usage, limits, and credit behavior
  • upstream API URL and forwarding behavior
  • optional environment-specific settings

Start simple. A product with one upstream, one meter, and one plan is easier to validate than a complete pricing catalog.

Publishing flow

When you publish a product, core compiles the builder-facing model into runtime artifacts. Those artifacts describe what the gateway needs to know:

  • which hostnames belong to the product
  • which credentials are valid
  • which plans and entitlements exist
  • which limits or credit checks apply
  • which upstream should receive allowed traffic
  • which shard policy should be used for hot runtime state

The gateway reads published runtime artifacts instead of calling core for every request.

Live request flow

Once live, the product behaves like a protected API:

  1. A subscriber sends a request to the product hostname.
  2. The gateway resolves the product and subscriber API key.
  3. The gateway checks the subscriber's active plan and constraints.
  4. The gateway forwards allowed traffic to your upstream.
  5. The gateway emits usage events.
  6. Core ingests usage for billing, analytics, and operations.

Editing a live product

Some edits are safe to make often, such as portal text or docs. Other edits can change runtime behavior and should be treated like a launch:

  • adding or changing meters
  • changing plan limits
  • changing credit behavior
  • changing upstream routing
  • changing public pricing

After a runtime-impacting edit, test with a real subscriber key before assuming production traffic is healthy.

Product docs

Product docs are not the same as platform docs. Product docs explain how to use a specific API. They should include:

  • authentication examples
  • common endpoints
  • request and response examples
  • rate limits and usage behavior
  • error handling
  • plan-specific notes

See Update product docs for the managed product docs flow.