Introduction

To accept admitted-applicant data from an SDI Consumer (an admissions system), your SMS implements a small, RESTful HTTP surface secured with OAuth 2.0. There is no SDK to install and no central network to join: a Consumer discovers you from one base URL, authorizes, reads the fields you expect, and posts records.

You can implement SDI incrementally. A minimal conformant Provider needs four things — discovery, one OAuth grant, a field schema, and an ingest endpoint — plus the ability to fetch documents if you intend to accept them. This guide walks each in order, with copy-pasteable examples.

Throughout, the running example Provider is https://sms.example.edu.

2. What you are building

flowchart LR
    C["Consumer<br/>(admissions system)"] -->|"1 GET discovery"| WK[".well-known/sdi-configuration"]
    C -->|"2 register / authorize / token"| OA["OAuth 2.0 server"]
    C -->|"3 GET expected fields"| SC["schema endpoint"]
    C -->|"4 POST records"| IN["ingest endpoint"]
    P["You (Provider)"] -.->|"5 resolve documents (you call out)"| C

You build	Purpose	Standard
Discovery document	Advertise endpoints, grants, scopes, capabilities	§5
OAuth 2.0 server	Authenticate and authorize the Consumer	§6
Field schema endpoint	Declare the fields you expect	§8.1
Ingest endpoint	Receive and apply records	§8.2
Document resolution client	Fetch document bytes from the Consumer	§10

Note the last row points outward: for documents, you are the caller — you fetch bytes from the Consumer. Everything else, the Consumer calls you.