Issue Summary

The JSM Ops Schedule Override API does not support client-defined identifiers (alias/metadata), making it impossible for automation tooling to reliably distinguish API-created overrides from manually created overrides in the UI. This breaks a key reconciliation pattern that customers currently use with Opsgenie.

Steps to Reproduce

1. Use an automation or script to create an override via POST /jsm/ops/api/{cloudId}/v1/schedules/{scheduleId}/overrides, providing responder, startDate, endDate, and rotationIds.
2. Later, list overrides via GET /jsm/ops/api/{cloudId}/v1/schedules/{scheduleId}/overrides and try to determine which overrides were created by the automation vs created manually in the JSM Ops UI.

Expected Results

• The API allows automation clients to attach a stable, client-defined identifier to overrides, for example by:
  • Allowing a custom alias to be set on create (parity with Opsgenie), and/or
  • Providing client-writable metadata / external ID fields on overrides that are returned by the GET endpoint.

• Automation tools can safely identify, update, and delete only the overrides they created, without risking modification of user-created overrides.

Actual Results

• The create endpoint generates its own alias value and does not allow clients to define it.

• There is no field on the override to store client-defined metadata or external identifiers.

• When overrides are reloaded via the API, automation cannot reliably distinguish automation-created overrides from user-created overrides, making safe reconciliation and lifecycle management across many schedules difficult.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available