Introduction

Scenario: Your Developer Console application is already scoped against the supply-chain Ontology, and the mission-command app team now needs a type-safe client to talk to it. You will generate the first versioned OSDK package and the auto-generated Ontology API reference so the app can read object types like Shipment without hand-writing REST calls.

Unit 2 turns the scoped Developer Console application from Unit 1 into something a developer can actually code against. The Ontology SDK (OSDK) gives you direct, type-safe access to the Foundry Ontology from your development environment: rather than crafting raw HTTP requests, you generate a package whose classes and properties mirror the exact object types, action types, and queries you selected. OSDK supports TypeScript via NPM, Python via Pip or Conda, Java via Maven, and other languages through OpenAPI, and the generated package is created and managed through Developer Console. This cohort is expected to code in TypeScript/React, so the worked path here is the TypeScript NPM SDK, with the other languages available as documented alternatives.

Generation is a versioning event, not a one-off export. When you select Generate first version in Developer Console, Foundry produces a concrete, numbered OSDK package plus generated Ontology API reference documentation and code snippets for the entities you scoped. That package is a client artifact: it lives in your package registry and your repository, and the access token it carries is scoped only to the ontological entities the application is allowed to touch, layered on top of the signed-in user's own permissions. Because the package and its install live entirely on the client side, no documented Foundry READ API can confirm that a particular SDK version was generated or installed; that part of the work is self-attested. What the platform can confirm is the Ontology the SDK binds to.

So this unit deliberately separates the attested work from the read-confirmable work. You will attest to generating and installing the package and to writing a first read snippet from the generated docs, while the one machine-checkable step verifies that the SDK targets a real, well-keyed object type, Shipment, that actually exists in the Ontology with a primary key and the properties your generated class will expose. That separation, attesting client-side artifacts honestly while proving the Ontology backbone the app consumes, is the discipline this whole course is built on.

Capability focus: OSDK package generation + versioning; the generated Ontology API reference; first read snippets (list/where). · Artifact: A generated, versioned OSDK package plus the generated Ontology API reference.

Key concepts

Companion video

1. 1

   Generate the first OSDK package version

   In Developer Console, open your scoped application and select Generate first version to produce the OSDK package, then install it into your project for the language your team uses; this cohort codes in TypeScript/React, so install the TypeScript NPM SDK (Python via Pip/Conda, Java via Maven, or OpenAPI for other languages are the documented alternatives). Treat this as a versioning event: the generated package is numbered and bound to the exact object types, action types, and queries you scoped, and it carries a token limited to those entities on top of your own permissions. This step is self-attested because package generation and installation happen in Developer Console and your package registry/repository; no documented Foundry READ API can confirm that a specific SDK version was generated or installed. Record the package name and version you generated so the rest of the team installs the same artifact.

   not startedself-attested

   Mark complete

   Self-attested: the OSDK package is generated and installed.

2. 2

   Verify the generated SDK targets a real, well-keyed object type

   This step is machine-checkable: it confirms that the object type your generated SDK binds to actually exists in the Ontology. Get Object Type (GET /api/v2/ontologies/{ontology}/objectTypes/{apiName}, requiring the api:ontologies-read OAuth2 scope) returns Shipment with its primary key and the properties such as status and etaDays that the generated SDK class will expose. Verifying this proves the SDK has a valid, well-keyed backing schema to read against; the check inspects the Ontology the app consumes, not the generated package itself, which remains a client artifact. If Shipment is missing or lacks a primary key, the SDK has nothing real to bind to, so resolve the scoping in Developer Console before continuing.

   not startedinstance check

   Run check

   Confirms Shipment exists with its primary key (the generated SDK targets a real object type).

3. 3

   Explore the generated Ontology API docs and write a read snippet

   Open the generated Ontology API reference for your scoped entities and use its code snippets to write a working OSDK read against Shipment, such as listing objects or filtering with a where clause on a property like status. Switch the documentation's language dropdown to confirm the same operation is expressed in TypeScript, Python, and cURL, which reinforces that the SDK is a thin, type-safe surface over the Ontology REST API v2 rather than bespoke plumbing. This step is self-attested: the snippet you write lives in your editor and the generated docs are part of your client-side package, so no documented Foundry READ API can confirm the code you produced. The companion read-confirmable proof that your read targets something real was established in the previous step, where Get Object Type confirmed Shipment and its primary key.

   not startedself-attested

   Mark complete

   Self-attested: a working OSDK read (list/where over Shipment) is written from the generated docs.