| AddSubjectRequest | The body of a receiver's request to add a subject to an Event Stream (SSF 1.0 Section 8.1.3.2). Success is an empty 200 - and deliberately proves nothing: a transmitter may silently ignore the addition, for example when the subject opted out of having events sent to this receiver, precisely so the response cannot be used to probe who is known to the transmitter (SSF 1.0 Sections 8.1.3.2, 9.1). |
| CreateStreamRequest | The body of a receiver's request to create an Event Stream: exactly the receiver-supplied members of the stream configuration, every one optional (SSF 1.0 Section 8.1.1.1). An empty body is well-formed - a transmitter reads a missing delivery as poll, and one that supports poll delivery answers with its own endpoint URL; one that does not may answer 400, so a caller should consult the advertised "delivery_methods_supported" first. |
| RemoveSubjectRequest | The body of a receiver's request to remove a subject from an Event Stream (SSF 1.0 Section 8.1.3.3). Success is an empty 204; as with adding, a transmitter may answer success without acting, so the response reveals nothing about who it knows (SSF 1.0 Sections 8.1.3.3, 9.1). |
| StreamConfiguration | An Event Stream's configuration: the document both sides contribute to and the transmitter returns whole (SSF 1.0 Section 8.1.1). Each member's doc says who supplies it, because that decides who may change it - a receiver's update carries the receiver-supplied members, and a transmitter-supplied member it echoes back must match the expected value exactly, a mismatch earning a 400; only a MISSING transmitter-supplied member is ignored (SSF 1.0 Sections 8.1.1.3, 8.1.1.4). |
| StreamMemberNames | The wire names of the Event Stream Management API members (SSF 1.0 Section 8.1). One registry rather than one per model, because the same member crosses several bodies - "stream_id" appears in the configuration, both status shapes, both subject requests and the verification request - and per-model copies of one name drift apart. |
| StreamStatus | An Event Stream's status document: one shape for both directions, because the read response (SSF 1.0 Section 8.1.2.1) and the update request and its echo (Section 8.1.2.2) carry the same three members. |
| StreamStatuses | The allowable stream status values (SSF 1.0 Section 8.1.2.1). A standalone registry rather than a nest under StreamStatus, because the Stream Updated Event carries the same values in its own payload. |
| TransmitterConfiguration | The transmitter's configuration metadata (SSF 1.0 Section 7.1): what a receiver learns from "/.well-known/ssf-configuration" before creating a stream - who the transmitter is, where its keys and endpoints live, and which delivery methods it speaks. |
| TransmitterConfiguration.AuthorizationSchemeUrns | The values an authorization scheme's "spec_urn" member may carry. |
| TransmitterConfiguration.DefaultSubjectBehaviors | The values the "default_subjects" member may carry (SSF 1.0 Section 7.1). |
| TransmitterConfiguration.ParameterNames | The wire names of the metadata members (SSF 1.0 Section 7.1). |
| TransmitterConfiguration.SpecVersions | The values the "spec_version" member may carry (SSF 1.0 Section 7.1): the numerical portions of the specification versions, per the working group's naming convention. |
| UpdateStreamRequest | The body of a receiver's request to update or replace an Event Stream's configuration: the stream's identifier plus the receiver-supplied members. One shape serves both verbs, whose difference is entirely in what ABSENCE means - under PATCH an absent member stays unchanged (SSF 1.0 Section 8.1.1.3), under PUT it is a request to delete, which is why PUT demands the full receiver-supplied set (Section 8.1.1.4). |
| VerificationRequest | The body of a receiver's request that a Verification Event be sent over an Event Stream (SSF 1.0 Section 8.1.4.2). Success is an empty 204, and it promises only that the event has been or will be transmitted - possibly asynchronously, in no particular order relative to the queue - so a receiver must not wait on it synchronously. |