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/Developer portals

Developer portals

Publish product pages, docs, pricing, and subscriber self-serve flows.

PreviousEnvironmentsNextBilling strategies

On this page

What subscribers use the portal forProduct page essentialsDocs inside a portalPricing and plansSubscriber self-serve

A developer portal is where subscribers understand and operate a product. It turns the product model into a customer-facing experience.

What subscribers use the portal for

Subscribers use portals to:

  • discover what the API does
  • read docs and examples
  • compare plans
  • subscribe to a product
  • manage API keys
  • understand usage and access state

The portal should make the first successful API call obvious.

Product page essentials

Every product page should answer:

QuestionExample answer
What does this API do?"Generate weather forecasts from a location."
Who is it for?"Teams embedding weather into apps."
How do I authenticate?"Use your subscriber API key as a bearer token."
What does it cost?"Starter includes 10,000 requests per month."
What happens when I exceed limits?"Requests are denied unless your plan allows overage."

Docs inside a portal

Product docs should focus on the product API, not the Farther Shore platform. Good product docs include:

  • a quickstart request
  • endpoint reference
  • authentication details
  • examples for common languages
  • usage and limits
  • response codes

Pricing and plans

Plan labels should match what subscribers see in billing and API errors. If a plan includes 100,000 requests / month, use the same meter name and unit in the docs.

Subscriber self-serve

Whenever possible, let subscribers handle the common path without support:

  • choose a plan
  • create an API key
  • rotate a key
  • inspect usage
  • understand why a request was denied

Support should be reserved for account and product questions, not basic access setup.