Introduction

Scenario: You are starting the mission command app that supply-chain operators will use to triage disruptions against the supply-chain Ontology, and your first job is to register and scope an OSDK application in Developer Console so it can reach exactly the entities it needs and nothing more.

Unit 1 sets the foundation for the entire build: before you write a line of React or call a single endpoint, you register a Custom Application in Developer Console and decide precisely what slice of the supply-chain Ontology it is allowed to touch. Developer Console is the place where you build and manage Custom Applications and their associated authorization (OAuth) clients and generated SDKs, treating Foundry as the backend for code you host inside or outside the platform. In this unit you create the application, choose its purpose, select the object types and action types the mission app consumes, and request the minimum OAuth2 scopes it needs.

This matters because OSDK is governance-aware by design. The token your application uses is scoped only to the ontological entities you select in Developer Console, layered on top of the signed-in user's own permissions to the data, so the app can never reach more of the Ontology than you deliberately grant it plus what the user could already see. Reads against the Ontology REST API v2 require the api:ontologies-read scope; you request api:ontologies-write only later and only if the app actually applies actions. Choosing the five supply-chain object types (Supplier, PurchaseOrder, Shipment, InventoryItem, DisruptionEvent) and the read scope now is what makes the rest of the course a least-privilege build rather than an over-broad one. This is a coding cohort: you are comfortable with TypeScript/React and OAuth2, and from here on the deliverables are client-side code plus the application configuration in Developer Console.

A note on what is and is not verifiable, because it shapes how this unit is graded. The application registration, the entity and scope selections, and the OAuth client configuration all live inside Developer Console's UI and are not exposed by any documented Foundry READ API, so most of this unit is honestly self-attested. The one thing a read confirms is the Ontology the app will be scoped against: that the five object types actually exist with primary keys, via the Ontology REST API v2. By the end of the unit you will have a registered Developer Console application pointed at the supply-chain Ontology, the read scope requested, and a short note documenting its least-privilege authorization model.

Capability focus: Developer Console applications; object/action-type selection; read-scope (api:ontologies-read) request; least-privilege authorization model. · Artifact: A Developer Console application registered against the Ontology with chosen entities and read scopes.

Key concepts

Companion video

1. 1

   Create the Developer Console application and choose its purpose

   Open Developer Console and create a new application with + New application, then choose a client-facing application as its purpose, since the mission command app is an interactive UI that operators sign into rather than a headless service. This single application is what will tie together the OAuth client, the generated OSDK, and (later) hosting and code-repository integration. This step is honestly self-attested: application creation and its purpose selection are Developer Console UI configuration, and no documented Foundry READ API exposes the registered application or lets a check confirm it exists, so your grader relies on your attestation that the client-facing application was created.

   not startedself-attested

   Mark complete

   Self-attested: a new client-facing application is created in Developer Console.

2. 2

   Confirm the target Ontology object types exist before scoping the app

   Before you scope the application, confirm the Ontology it will point at is actually present. Using the Ontology REST API v2, List Object Types (GET /api/v2/ontologies/{ontology}/objectTypes, requiring the api:ontologies-read scope) returns each object type's apiName together with its primary key, and you are verifying that the five supply-chain object types the mission app consumes (Supplier, PurchaseOrder, Shipment, InventoryItem, DisruptionEvent) each resolve with a primary key. This is the one independently read-confirmable artifact in the unit: it proves the Ontology the app will be scoped against exists. It deliberately does not confirm that you added those types to the Developer Console application, because that selection is UI-only and not read-API-exposed.

   not startedinstance check

   Run check

   Confirms the five supply-chain object types exist (each with a primary key) for the app to scope.

3. 3

   Select object/action types and request read scopes

   Back in the application's configuration, add the object types the mission app reads (Supplier, PurchaseOrder, Shipment, InventoryItem, DisruptionEvent) and the action types it will later need, then request the least-privilege scope api:ontologies-read for the read flows that dominate this course. Request api:ontologies-write only if and when the app applies actions; do not request it now just because actions exist in the Ontology, as over-broad scopes are exactly what least-privilege design avoids. This step is self-attested: which entities you added and which scopes you requested are configured inside Developer Console and are not exposed by any documented Foundry READ API, so the grader trusts your attestation here while the prior step independently confirmed the entities themselves exist.

   not startedself-attested

   Mark complete

   Self-attested: the needed object/action types are added and api:ontologies-read is requested (least-privilege).

4. 4

   Document the application's authorization model

   Write a short note documenting the application's authorization model so the team understands the trust boundary you just drew. State which object and action types the app token can touch, and explain that the OSDK token is scoped only to those selected entities in addition to the signed-in user's own permissions, which is what prevents the app from reaching anything you did not deliberately grant. Note that only api:ontologies-read is requested for the read flows and that write scope is deferred until an action is genuinely applied. This step is self-attested by design: the authorization model lives in Developer Console configuration with no documented READ API to confirm it, and the deliverable is your written, defensible account of why this least-privilege scoping protects governed supply-chain data.

   not startedself-attested

   Mark complete

   Self-attested: a note records which entities the app token can touch and why least-privilege read scoping protects the mission.