Field-level exposure & PII
Contracts let you select both the endpoints and the fields described to consumers. Review suggested PII and internal-field flags, then choose which fields to expose and how to describe them.
Field selection shapes the generated contract definition. Verify runtime behavior separately for the surface you publish.
The field table
The Schema step groups your selected endpoints by service — an identity service here, an inventory API there — with each endpoint showing its exposure count at a glance ( 2/2 Fields, 12/15 Fields ). Expand one and every field becomes a row you control:
Column | What you control |
Include checkbox | Whether the field exists in this contract at all — unchecked fields vanish from every generated artifact |
Field & badges | The field name, flagged with PII or Internal when it carries sensitive or non-public data |
Type | The field's data type, editable from a dropdown |
Value | An example value consumers and agents will see in the generated spec and docs |
Description | Human-and-model-readable meaning ("User's primary email address") |
More | Mark the field required or add constraints |
Bulk decisions in one click
Nobody wants to toggle 58 checkboxes by hand. Quick actions apply a policy across the whole contract — or, with the “This endpoint only” variant, to a single endpoint, with Restore defaults as the undo:
- Include all — start from full exposure and trim down.
- Required only — expose the minimal viable surface.
- Exclude PII — drop every flagged personal-data field at once.
- Exclude internal — drop everything marked internal-only.
A search fields box gets you to any field in a large contract instantly, and the AI assistant does the same work conversationally — “mark every ID required and exclude all PII” is a sentence, not a session.
The tally that keeps you honest
The wizard footer carries two numbers everywhere you go: Exposed fields (say, 49/58) and a warning-colored PII Exposed count. If the contract ships with 18 PII fields exposed, that happened in full view — not as a surprise in a security review six months later.
Field exposure controls the generated contract spec and supported artifacts. TypeScript and Python SDK publishing is coming soon. Do not assume removing a field from documentation changes the upstream API's response.
Preview: contract-generated MCP response filtering can return only properties allowed by the reviewed response schema. This applies to compatible contract MCP deployments, not automatically to ordinary collection MCP servers.
Where to go next
Publishing targets
Publish the reviewed API through supported spec, documentation, MCP, and mock-server destinations. SDK publishing is coming soon.
Governance & stakeholders
Breaking-change policy, validation rules, and who signs off before a publish.
Response filtering and its limits
For supported contract MCP deployments, the response is projected onto the contract's allowed fields, including supported nested objects and arrays. Unsupported schemas, unexpected error responses, and non-JSON responses can be withheld instead of returning an unfiltered payload. Test success, error, nullable, nested, and array responses before sharing the tool.
Keep response schemas explicit. Dynamic keys, unresolved references, and ambiguous schema combinations may require a simpler schema or may be rejected. The upstream API remains responsible for authorization and tenant isolation; field filtering does not decide which customer's records a caller may read.
On this page
- Field-level exposure & PII