Developer portal

Sides

The Customer's developer, account owner, payer and agents

Unit of work

Key, usage against Limits, request; the Customer's own analytics

Examples

• Developer dashboards

The five tests

1. who signs in
2. which record dominates
3. who acts next
4. how money moves
5. who may settle what

Carried only by it, from What every App needs

Exactly-once metering against real-time Limits; keys as a security product; version pins; the Customer's usage with a typed projection

Screens its Interfaces name, by reader

Anyone, before sign-in

Pricing from the same record the gate enforces · docs · a keyless capped call · an anonymous sandbox · status · changelog

Developer

First run · keys · request log with refusals grouped by what refills them · webhooks with deliveries · Test mode · version · an object inspector for stateful APIs

Every Customer reader

Usage per API in each counting unit against each Limit, over a declared window · cost so far and a typed projection to period end · what this period would cost on another Offer · bill lines explained by their Events · free and refused acts · outcomes · delivered reports with their run receipts · spend alerts

Owner, admin, payer

Offer · billing · credits · team · Mandates and pending Approvals · Credentials for access-gated Offers · compliance · settings with every "view as" entry the Business's operators left

Customer admin, for its agents

Tools the Business exposes, with scope and side effects · agent seats with who deputized each · the approval policy for side-effecting tool runs · traces per session

Data product Customer

Sharing

Assurance reader

Release gates with measured values for the pinned Version · dataset provenance · audit export · sign-off

Build today: the Site pages around it

• api-product Template
• endpoints
• api-call
• Harbor tides

9actors6workflows10records

A developer portal is the App where a Customer builds on a Business's API, Dataset, SDK or agent endpoint. It has two halves of equal weight. The account plane gets the Customer in, fixes failed calls and takes payment. The Customer's own analytics says what was used, in which unit, its projected cost at period end, and what the product delivered and refused.

It is a projection of the API, not a layer over its own tables. Every control is a Verb the API exposes, and every figure is a reading the gate and the books also use.

Any Business that sells programmatic access ships one: a data vendor, a payments company, a law firm with an API. startupbuilder.dev once named this App kind Dashboard; a Dashboard is now the View this App renders, not the App. The study describes the work; how an App is defined is open, see What every App needs.

Customer5 actors

• DeveloperWorkReaches a first 2xx, then keeps it working: keys, logs, webhooks, Test
• Account ownerWorkAccepts the Offer, signs Mandates, closes or transfers the account
• Admin, payer, viewerWorkTeam, spend caps, plan; invoices and receipts read-only
• Assurance readeroften a clinical or compliance leadWorkReads release gates and data provenance; signs off a Version for go-live
• Outside implementerinvitedWorkWorks in a sandbox with no access to live data

For the developer1 actor

• Coding agentWorkReads the docs and machine registers, mints a Test key, calls, reads the log, wires the integration

For the Customer1 actor

• Runtime agentunder a MandateWorkCalls live and tops up within its ceiling

The Customer's own customers1 actor

• Sub-tenantsWorkExist for platform Customers; their usage embeds in the Customer's App

The Business1 actor

• Support, risk, founderWorkRead the same records from Admin, never from here

1. 01
   Workflow 1: Stranger to first 2xx

   1. 1.1A pricing choice rides through sign-in.
   2. 1.2The key is revealed once inside a snippet, the call lands live, and onboarding completes at the first call, not at signup.
2. 02
   Workflow 2: Agent first

   1. 2.1An agent calls keyless within a free allowance, mints a Test key and scripts against fixtures.
   2. 2.2It may pay for reversible scope, such as data or sandbox calls, where the Business allows it.
   3. 2.3Any scope that carries a legal agreement waits on a human signer through a link that shows the worst case in dollars.
3. 03
   Workflow 3: Call, inspect, fixSupport, risk, founder

   1. 3.1A refusal carries its class and cure.
   2. 3.2Errors group by code, each with a docs page and a Test trigger.
   3. 3.3"Ask support about this request" carries the request id.
4. 04
   Workflow 4: Read, project, alert

   1. 4.1Usage reads in the unit the Offer bills, over a window that names its source: the billing period or the calendar month.
   2. 4.2A projection is a straight line labelled as one, never shown under a day.
   3. 4.3A spend alert informs and never limits, and a failed read renders "Usage unavailable", never zero.
5. 05
   Workflow 5: Govern the Customer's agentsAdmin, payer, viewer

   1. 5.1The admin grants tool scopes, deputizes agents with a ceiling and an expiry, and sets which tool runs need a human.
   2. 5.2Each approval binds to the hash of what was shown.
6. 06
   Workflow 6: Regulated go-liveAssurance reader

   1. 6.1Test works at once; live waits on a business profile in third-party review, a buyer's credential, or the assurance reader's sign-off.
   2. 6.2The portal names who must act next.

Account14 states

1. anonymous
2. identified
3. verified
4. delegated
5. new
6. keyed
7. activated at the first 2xx
8. active
9. over a Limit
10. trialing
11. scheduled to cancel
12. past due
13. dormant
14. closed

Key5 states

1. revealed once
2. active
3. rolling with grace
4. revoked or expired
5. Test or Live

Call5 states

1. received
2. allowed or refused
3. served
4. rated
5. billed or not billed

Refusal3 states

1. clock (429 with a retry time)
2. settlement (402 with a checkout cure)
3. human (403 with a claim or Approval link)

Reading7 states

1. present
2. unavailable
3. partial
4. early
5. a projection typed early
6. metered
7. capped or contract

Webhook delivery4 states

1. first try
2. retrying
3. succeeded or exhausted
4. sent again

Subscription, Invoice, credit balance5 states

1. startupbuilder.dev's states
2. a credit balance runs funded
3. low
4. empty
5. topped up

Mandate and Approval4 states

1. active
2. near ceiling
3. Approval pending
4. expired or revoked

Sharing grant2 states

1. active
2. revoked and kept as evidence

Version pin6 states

1. pinned at the first call
2. upgrade available
3. testing
4. upgraded
5. rolled back
6. sunset

ActorsCopy Anchor Link

One person often holds owner, developer and payer on day one. A design that merges them breaks at the second person.

InterfacesCopy Anchor Link

The analytics half is a set of Dashboards, each a View of one Customer's scope rendered as screens, Markdown and JSON. What only this type adds is the content: counting units against Limits, a projection to a billing boundary, and outcome classes that are also money.

Analytics sold as the Product, such as scheduled market reports to a Customer's Slack, is an Offer delivered here and through channels, not a separate App.

Records and actionsCopy Anchor Link

The type has no single dominant record. It is a cluster of small lifecycles around one Customer account. For a stateful API, the API's own work record joins them at the center: a matter, a claim, a pallet's chain of custody. Its performer may be a human or an agent, doing digital or physical work.

The Verbs group by record. Account: claim, answer, leave, close. Key: create, reveal once, roll, revoke, scope, tag as agent. Webhooks: create, send again, replay since, rotate secret.

Money: accept an Offer, switch, cancel, resume, add credits, set a cap. Agents: grant a tool scope, deputize, approve a tool run. Sharing: share, stop sharing. Version: pin, test an upgrade, roll back.

TermsCopy Anchor Link

Terms6 quoted from startupbuilder.dev · 2 it lacks · 0 colliding

Term	In startupbuilder.dev	Definition, quoted from startupbuilder.dev or the gap
Customer	Customer	"A Customer is a party that has accepted an Offer from a Startup at any price, including zero." Read for any Business.
Limit	Limit	"A Limit is a bound on a Permission, Entitlement, or Mandate, checked before every call; exceeding it creates an Approval."
Mandate	Mandate	"A Mandate is a standing authorization for an Agent to act for a Party, within Permissions and Limits, until it expires."
Dashboard	Dashboard	"A Dashboard is one unified view of a scope, rendered as Markdown for Agents, screens for Humans, and JSON for native clients." Each analytics View here is one; the App is not.
Access Level	Access Level	"An Access Level is a named preset of Permissions a Worker holds in a namespace, such as owner or viewer; it is never a Role." A Customer's members are not the Business's Workers, so this type has no access unit for them.
Credential	Credential	"A Credential is a standing authority a regulator grants a person or entity to perform certain acts in a jurisdiction." It covers supply; a buyer's credential that gates access is a gap.
API key, Test twin, call record, delivery	lack	startupbuilder.dev withdrew its key Noun and has a mode, not a twin.
Counting unit, projection kind, sharing grant	lack

WorkflowsCopy Anchor Link

1. Stranger to first 2xx. A pricing choice rides through sign-in. The key is revealed once inside a snippet, the call lands live, and onboarding completes at the first call, not at signup.
2. Agent first. An agent calls keyless within a free allowance, mints a Test key and scripts against fixtures. It may pay for reversible scope, such as data or sandbox calls, where the Business allows it. Any scope that carries a legal agreement waits on a human signer through a link that shows the worst case in dollars.
3. Call, inspect, fix. A refusal carries its class and cure. Errors group by code, each with a docs page and a Test trigger. "Ask support about this request" carries the request id.
4. Read, project, alert. Usage reads in the unit the Offer bills, over a window that names its source: the billing period or the calendar month. A projection is a straight line labelled as one, never shown under a day. A spend alert informs and never limits, and a failed read renders "Usage unavailable", never zero.
5. Govern the Customer's agents. The admin grants tool scopes, deputizes agents with a ceiling and an expiry, and sets which tool runs need a human. Each approval binds to the hash of what was shown.
6. Regulated go-live. Test works at once; live waits on a business profile in third-party review, a buyer's credential, or the assurance reader's sign-off. The portal names who must act next.

BoundariesCopy Anchor Link

• The Organization is the partition, and keys belong to it, not to a member. A member who leaves breaks nothing.
• The Business's operators never see key values, request bodies, webhook payloads or payment details. A "view as" needs a reason, is time-boxed, and leaves an entry the Customer reads.
• A deputized key's rates are a rate on the deputizing person, so they render to that person and the owner only.
• Embedded usage for sub-tenants takes the tenant from the authenticated principal, never from a parameter alone.
• Stopping sharing stops future reads and cannot recall data a partner already pulled; the control says so.
• One identity across many Businesses on one platform never reveals to one Business that the Customer buys from another.
• The App's owner and its screens' owner can differ. A portal shared across a family of Businesses carries each Business's domain Views in named slots, under that Business's Brand only.

AgentsCopy Anchor Link

Hard partsCopy Anchor Link

1. One source of truth for price, Limit, refill and state. The portal, the gate, the books and the SDK read one row per rule, or they drift within days.
2. Counting units are separate Metrics. Requests, raw calls and billable calls diverge on repeat lookups. A tile with one unit under another's label is a lie about money.
3. Unavailable is not zero. A page a suspended Customer needs to pay is never taken down by a usage read that throws.
4. One bound, two refills. A monthly cap is refilled by the clock and by an upgrade; the refusal needs one status and may carry two cures.
5. Exactly-once metering. Late and out-of-order events, Limits checked before every call, counters shown later, and every bill line explainable.
6. Governing someone else's agents. Scopes per tool, approvals bound to a hash, traces under one request id, and policy that retrieved text cannot change.
7. Assurance has a basis. A gate not run never shows as passing, and a synthetic suite says so.
8. The state explosion. Account states, refusal classes, reading presence and work-object waits multiply across screens. A matrix that derives states from gate outcomes, and fails on a missing one, is the specification.

Day oneCopy Anchor Link

Before any portal, a Business publishes docs, machine registers, pricing, a capped keyless call and an MCP server under its own Brand, with a checkout link for prepaid credits.

The first Customer needs:

• sign-in with one owner, and a first run;
• keys with a Test twin;
• usage in the unit the Offer bills, over a declared window, with a typed projection and an honest "unavailable";
• credits always shown, and the 402 with a checkout cure;
• the request log, with refusals grouped by refill class;
• support prefilled with the request id, and an account brief an agent can read.

A Startup reaches this type first because its first Product is so often an API. An established Business often needs the later rows first: contracts, SSO, roles, audit, migrated keys and, in regulated domains, the assurance reader.

Related studiesCopy Anchor Link

Prototypes this study needsCopy Anchor Link

1. 01

   Does one measurement guard hold every per-person view?

   Run a performer's Register, a firm roster, a team queue, capacity per credential, a Role Review of a human seat and a deputized agent key through one guard; output pass, own, withheld or fail per audience.

   names: key
2. 02

   Does one hold serve every engine?

   A multi-capacity hold raced by two bookers, reused for a shift, inventory and a Limit check.

   names: Limit