# API spec typo: WorkItemTypeManualWorkItems contains "PolicyVioloation"

**URL:** <https://developer.sailpoint.com/discuss/t/api-spec-typo-workitemtypemanualworkitems-contains-policyvioloation/221486>\
**Category:** Bugs\
**Tags:** apis, identity-security-cloud\
**Created:** [September 4, 2026, 4:55pm UTC](https://developer.sailpoint.com/discuss/t/api-spec-typo-workitemtypemanualworkitems-contains-policyvioloation/221486 "2026-09-04T16:55:15Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Pratyush27](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/pratyush27/32/36795_2.png) [@Pratyush27](https://developer.sailpoint.com/discuss/u/Pratyush27)\
**Post date:** [September 4, 2026, 4:55pm UTC](https://developer.sailpoint.com/discuss/t/api-spec-typo-workitemtypemanualworkitems-contains-policyvioloation/221486/1 "2026-09-04T16:55:15Z")

</div>

# What problem are you observing?

The `WorkItemTypeManualWorkItems` enum in the ISC API specification contains the value **`PolicyVioloation`**. The correct spelling is `PolicyViolation`.

The enum backs the `type` property on the work item object, so it reaches `GET /work-items`, `GET /work-items/{id}` and `GET /work-items/completed`, and it propagates into every generated SDK. Anyone coding against the SDK enum picks up the misspelled literal.

The misspelling is present in **v3, v2025 and v2026**. **v2024 has it spelled correctly** , which suggests a regression rather than a deliberate value.

I raised this in July and it is still open:

- Issue: [API Spec for Work item type has a typo · Issue #138 · sailpoint-oss/api-specs · GitHub](https://github.com/sailpoint-oss/api-specs/issues/138)
- PR: [FIx: API Spec for work item type contains typo for PolicyViolation by pratyush270394 · Pull Request #137 · sailpoint-oss/api-specs · GitHub](https://github.com/sailpoint-oss/api-specs/pull/137)

I’m unsure if `api-specs` accepts pull requests. The PR is added as the diff for reference only.

# What is the correct behavior?

The enum value should read `PolicyViolation`.

I was assuming the reason this has not been corrected is uncertainty over if changing the string would break existing consumers, so I tested what the API actually emits. Details under steps to reproduce. **Across an entire tenant, neither spelling is emitted at all**

Could someone confirm internally whether any service emits `PolicyVioloation`, and if not, get the spelling corrected in the source spec?

# What product feature is this related to?

Identity Security Cloud, **Work Items API**. Schema `WorkItemTypeManualWorkItems`. Affects API versions **v3, v2025, v2026**. Not present in v2024.

# What are the steps to reproduce the issue?

To observe the typo itself, open the `WorkItemTypeManualWorkItems` schema in the v2026 spec and read the enum members.

To reproduce, in a sandbox tenant, using HTTP

1. Enumerate all identities via `POST /v2026/search` with `searchAfter` paging (1914 identities in my tenant).
2. Call `GET /v2026/work-items/summary?ownerId=` for each identity to find owners holding items (7 in my tenant).
3. Page `GET /v2026/work-items` and `GET /v2026/work-items/completed` to exhaustion for each of those owners and collect every distinct raw `type` value.

The only values returned tenant-wide were `ManualAction` (489), `Form` (7) and `Remediation` (11). Neither spelling of `PolicyViolation` appeared, and neither did `ViolationReview`.

1. My tenant had no SOD policies, so I created one and triggered a genuine violation.
2. Re-ran the sweep. No new work item was created.
3. Submitted an access request that breached the policy (`POST /v2026/access-requests`). The violation fired and was recorded on the access request record itself:

```json
"accessRequestPhases": [
  { "name": "SOD_PHASE", "state": "COMPLETED", "phaseReference": "sodViolationContext" }
],
"sodViolationContext": {
  "state": "SUCCESS",
  "violationCheckResult": { "violatedPolicies": [...] }
},
"approvalIds": [],
"approvalDetails": [],
"manualWorkItemDetails": null

```

**No work item was generated.** SOD violations surface as `sodViolationContext` on the access request, not as work items, which, i am really guessing here, is consistent with this enum value being inherited from IdentityIQ and unused in ISC.

# Do you have any other information about your environment that may help?

Sandbox tenant, pod `stg02-eucentral1`. Calls made with Python `requests` directly against the v2026 API, `ORG_ADMIN` authority.

The policy I tested had `preventSetting: null`. I have not tested a prevent-configured policy.