chore: update control openapi spec

[knock-eng-bot]

Automated PR created from GitHub Actions workflow from knocklabs/control release (v0.1.1383).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	May 26, 2026 6:10pm

[cursor]

Risk MEDIUM: Automated OpenAPI spec update adds new partial preview schemas and endpoint from control release v0.1.1383.

Reasons

• Only one file changed (data/specs/mapi/openapi.yml), which is an OpenAPI specification file — this triggers MEDIUM risk per classification rules.
• The diff is additions-only (144 lines added, 0 deleted), adding new PreviewPartialRequest, PreviewPartialResponse schemas and a POST /v1/partials/preview endpoint.
• The change is automated (created by knock-eng-bot via GitHub Actions), which is typical for spec updates but still warrants a check on API reference rendering.
• No .tsx/.ts component, layout, library, or style files are modified, so HIGH risk is not triggered.
• No sidebar, content, or build configuration changes are included.

Notes

• Verify that the new PreviewPartialRequest and PreviewPartialResponse schemas render correctly in the API reference documentation.
• Confirm the new /v1/partials/preview endpoint page appears as expected and the Partials tag grouping is correct.
• The x-struct and x-validate fields reference Elixir modules — ensure these are handled gracefully by the docs renderer.

  

_{Sent by Cursor Automation: Docs PR classifier}

[cursor]

Inconsistent field naming commercial vs is_commercial

Medium Severity

The newly added field in PreviewTemplateRequest.workflow is named commercial, while every other schema in the spec uses is_commercial for the same concept (e.g., WorkflowRequest.settings.is_commercial, BroadcastRequest.settings.is_commercial). This naming inconsistency means API consumers familiar with is_commercial from workflow and broadcast endpoints will likely use the wrong field name when calling the template preview endpoint.

Additional Locations (1)

• data/specs/mapi/openapi.yml#L2886-L2892

 

^{Reviewed by Cursor Bugbot for commit 5383ed2. Configure here.}

[cursor]

Environment parameter inconsistently optional for listSourceEvents

Medium Severity

The listSourceEvents endpoint marks the environment query parameter as required: false, while the sibling endpoints getSource and setSource on /v1/sources/{key} both mark environment as required: true. The endpoint description itself says it returns events "in the requested environment," implying the parameter is expected. Any SDK generated from this spec would allow omitting environment for this endpoint, potentially causing server-side errors or unexpected behavior.

Additional Locations (2)

• data/specs/mapi/openapi.yml#L11352-L11353
• data/specs/mapi/openapi.yml#L11384-L11385

 

^{Reviewed by Cursor Bugbot for commit cced03c. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 29930e7. Configure here.}

[cursor]

Missing format: date-time on timestamp field

Medium Severity

The last_event_received property in SourceStatusResponse is missing format: date-time, despite being described as a timestamp and having a datetime example ("2026-05-11T16:00:00Z"). Every other timestamp field in the new schemas (e.g., inactive_at in the same schema at the mappings_requiring_commit level, last_received_at in SourceEvent, inserted_at in SourceLog) includes format: date-time. This omission will cause SDK code generators to treat the field as a plain string instead of a datetime type.

 

^{Reviewed by Cursor Bugbot for commit 29930e7. Configure here.}