Targets and deliveries
Choose what Typeship maintains, then configure where each independently reviewed Target is delivered.
A Target is one customer-selected surface Typeship maintains from a Definition:
| Target | Result |
|---|---|
cli | Agent-friendly command-line interface |
mcp | Search, read, and execute MCP server |
typescript-sdk | Native TypeScript SDK |
python-sdk | Native Python SDK |
go-sdk | Native Go SDK |
All five are peers. A Project can be CLI-only, MCP-only, SDK-only, or any non-empty combination.
More than one Target may use the same generator. For example, public and internal TypeScript SDKs can have different identities, configuration, repositories, and release histories.
Each Target inherits Project.config and may store overrides. GraphQL settings remain on the Definition.
Choose a separate Target whenever consumers need a separate package identity, configuration, destination, or release decision. Do not create separate Targets merely because one package is delivered to two places. See Choose Targets for concrete combinations.
Deliveries
Targets answer what Typeship maintains. Deliveries answer where it goes and under what identity.
| Delivery setting | Behavior |
|---|---|
| TypeScript or Python package name | Sets the registry identity. |
| Go module path | Defaults to the destination repository and may be overridden. |
| Repository | Selects the GitHub destination. |
| Directory | Gives the Target ownership of one generated subtree. |
Different Targets may share a repository only when their directories do not overlap. This ownership rule applies across the organization and prevents competing release pull requests from replacing each other's files.
CLI and MCP are not hidden inside a TypeScript SDK. They contain the request runtime they need, but neither selects, exposes, or bills a public TypeScript SDK. Hosted MCP is enabled with the MCP Target by default.
Turning a Target off stops future generation and its hosted service. It does not delete code already delivered or packages already published. Delivery settings remain saved so turning the Target back on does not erase its identity.
Generator editions
Every Target pins a generator edition, a dated compatibility contract for the files Typeship emits.
Each Generation records the edition, engine build, configuration hashes, public-surface plan, endpoint entitlement, Definition Revision, and package version. This provenance stays in Typeship. Private source coordinates do not appear in destination repositories.
Typeship never silently upgrades a Target to a new edition. An unavailable edition returns edition_unavailable.
Upgrade tooling can generate and review a new edition before changing the Target. Engine fixes within an edition may change implementation details but must preserve its public contract.
Package releases
Package versions belong to Targets, not Projects or Definitions.
current_versionadvances only after the destination candidate merges.proposed_versionis the version requested for the next candidate.- Release readiness compares the proposal with the minimum SemVer change required by the cumulative unreleased diff.
Each merge creates an immutable rel_* Target Release. It records the Generation, Definition Revision, destination repository, and delivery revision that shipped.
On Pro, billing is per selected Target. Each Target includes 150 operations from the complete patched Definition, then pays for each additional operation it generates. See Plans and limits.
List Targets with GET /projects/{project_id}/targets and create one with POST /projects/{project_id}/targets. Retrieve or update one at /targets/{target_id}. Deliveries are nested resources on the Target, and releases live at /targets/{target_id}/releases. A Target's generator and definition_id are immutable.