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/Start/Launch checklist

Launch checklist

The practical checklist for taking a product live.

PreviousCore conceptsNextProducts

On this page

Product setupBilling setupGateway setupUsage and billing setupSubscriber experienceOperational checksSuggested launch sequence

Use this checklist before sending real subscribers to a Farther Shore product.

Product setup

  • Product name, display name, and description are final enough for subscribers.
  • Upstream URL points at the intended production API.
  • Required upstream authentication is configured.
  • Public portal copy explains the value of the API.
  • Product docs include at least one working request example.

Billing setup

  • Billing strategy matches how customers should buy the product.
  • Every public plan has a clear name, price, and usage behavior.
  • Included usage, hard limits, overage, or credit rules are intentional.
  • Test subscription was created on the plan you expect to launch.
  • Any external payment setup is connected and tested.

Gateway setup

  • Product hostname resolves to the gateway.
  • A test API key can call the product through the gateway.
  • Missing, invalid, and revoked keys fail with expected errors.
  • Requests over a configured limit are denied.
  • Allowed requests reach the upstream API.

Usage and billing setup

  • Usage events arrive in core after gateway traffic.
  • Meter names match the plan configuration.
  • Estimated and actual usage behavior is understood.
  • Billing totals match the expected usage calculation.

Subscriber experience

  • Subscriber can find the product in the developer portal.
  • Subscriber can choose a plan.
  • Subscriber can create or view an API key.
  • Subscriber can copy an example request and receive a successful response.
  • Error messages are understandable enough to self-correct common mistakes.

Operational checks

  • Stage product was tested before production.
  • Product owner knows how to revoke a key.
  • Product owner knows how to update product docs.
  • Product owner knows where to look for denied request and usage issues.
  • Launch traffic expectations are known so gateway scaling can be monitored.

Suggested launch sequence

  1. Validate the product in stage.
  2. Publish production configuration.
  3. Create an internal subscriber and test API key.
  4. Send gateway traffic through the public product hostname.
  5. Confirm usage events arrive in core.
  6. Invite the first external subscriber.
  7. Watch usage and denied-request patterns during the first traffic window.