Version localizada en revision
Esta pagina aun no esta disponible como norma localizada revisada. Use la fuente inglesa autoritativa para lenguaje normativo, interpretacion de esquemas, obligaciones de implementacion y limites de soporte.
Cómo usar esta página
Use this page to inspect the live REST routes, OpenAPI document, copyable machine-facing starter requests, and the reference mock exchange.
Machine Surface
Start from the catalog, then move into the adoption kit, OpenAPI, validation, and live mock exchange
This page exists to stop implementers from reverse-engineering the WordPress REST surface. Resolve the live routes here, then move into the onboarding bundle, validation, mock-response testing, problem-detail handling, or pack assembly without guessing. Generated .uai package files are local memory and handoff records, not API endpoints or hosted enforcement routes.
Resolve first
Catalog and discovery
The catalog and discovery routes tell automation what the current public surface is before any route-specific call is made.
Describe contract
OpenAPI and starter requests
Use the live OpenAPI export and the starter request patterns here instead of relying on scraped page copy or stale notes.
Carry forward
Adoption, validation, and reusable evidence
The route inventory matters most when it feeds the adoption bundle, a validator run, a live mock response, or a conformance packet that can travel into release review.
Search boundary
HTML pages explain; JSON routes execute
Machine JSON routes are marked as non-indexable execution surfaces with explicit cache policy, so search and citation should prefer the human documentation pages.
HTTP failures
Problem JSON is the recovery contract
Route lookup failures, malformed public POST bodies, body-size limits, and rate limits return RFC 9457-style application/problem+json with UAIX codes, retry guidance, evidence flags, and safe-harbor links.
Live routes
CatalogCurrent public standards inventory.DiscoveryMachine-facing route manifest.Adoption Kit JSONPublished onboarding bundle for first-proof runs.OpenAPI JSONLive OpenAPI 3.1 export.ValidateMachine POST target for conformance checks.Mock ExchangeMachine POST target for a live conforming response envelope.Conformance Pack JSONReusable launch packet in one response.
Proof path
Validator-backed proof path
Keep the public reading order tied to one evidence trail: profile, schema, example, validator result, and release record.
- 1Pick a message profile.Start with a published UAI-1 profile and the record family that matches the exchange you need to prove.
- 2Compare it with schemas and examples.Resolve the schema, registry entry, and one fixture before writing or mapping your candidate packet.
- 3Run validator evidence.Validate keyed, minified-keyed, or keyless JSON against the current public UAI-1 records.
- 4Attach the result to implementation or handoff records.Carry the exported result into Conformance Pack, implementation track, changelog, or Project Handoff evidence.
curl -s https://uaix.org/wp-json/uaix/v1/catalog
curl -s https://uaix.org/wp-json/uaix/v1/discovery
curl -s https://uaix.org/wp-json/uaix/v1/adoption-kit
curl -s https://uaix.org/wp-json/uaix/v1/openapi.json
curl -s -X POST https://uaix.org/wp-json/uaix/v1/mock-exchange -H "Content-Type: application/json" -d @mock-exchange-request.jsonUse the catalog and discovery routes first, then pull the adoption kit, inspect the OpenAPI document, or request one live mock response directly.