feat(order): Get Order operation w/ platform-auth#276
Open
feat(order): Get Order operation w/ platform-auth#276
Conversation
richmolj
requested review from
DanielFalconGuedes,
MitkoDeyanovMitev,
carol-w-tech and
westeezy
Add synchronous GET endpoint for order retrieval, complementing the
existing webhook push mechanism. Both return the same current-state
snapshot shape - webhooks deliver proactively to avoid polling, GET
provides on-demand access for reconciliation and conversational use.
Authorization model:
Who - MUST authenticate (non-negotiable, any UCP mechanism)
What - MAY scope access (platform credentials -> own orders,
buyer authorization -> buyer's orders, or custom policies)
MAY omit or redact fields based on context or business policy
When - MAY enforce data availability (retention, erasure)
3 tasks
jingyli
reviewed
Apr 3, 2026
Contributor
jingyli
left a comment
jingyli
left a comment
There was a problem hiding this comment.
Added some general style-related comments to make sure we are consistent with the most up-to-date UCP design patterns.
Add missing required fields to all response examples: - `currency` field (required since #283) to order response examples - `severity` field to error message examples per message_error.json
- Discovery: match service.json array-of-bindings shape with transport
discriminator; use {{ ucp_version }} templating throughout
- Errors: use error_response.json envelope (ucp.status: "error") instead
of partial order shape; add oneOf[order, error_response] to OpenAPI and
OpenRPC result schemas
- Capabilities: use consistent array format with name field across all
examples (success + error, REST + MCP)
- Add missing required fields: currency in responses, severity in errors
Operations (platform→business) and Events (business→platform) have fundamentally different interaction models. Separating them clarifies directionality and avoids implying webhooks are platform-invoked operations. - Operations: narrowed to Get Order with platform-specific guidelines - Events: new top-level section for webhook push with business-specific guidelines - Guidelines distributed by concern instead of one mixed section
Behavioral requirements (webhooks-primary, ephemeral data, auth) now live in order.md Guidelines only. Binding conformance sections retain transport-specific rules (TLS, message signing, messages check, permalink delegation) and cross-ref the capability-level guidelines.
Contributor
|
@jingyli ty for thorough scrub! Addressed the feedback, ptal. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add synchronous GET endpoint for order retrieval, complementing the
existing webhook push mechanism. Both return the same current-state
snapshot shape - webhooks deliver proactively to avoid polling, GET
provides on-demand access for reconciliation and conversational use.
Authorization model:
Type of change
Checklist