API
Update case types
Update case types. This applies only the supplied changes.
/api/case-types/{caseTypeId}Update case types. This applies only the supplied changes.
Operation IDpatchapiCaseTypesCaseTypeIdOperation details
Purpose
Update case types. This applies only the supplied changes.
When to use it
Use this when the caller has read the current state and is authorised to change the documented fields or lifecycle state.
When not to use it
Do not use this to create an unrelated resource or bypass a purpose built transition, validation, or permission check operation.
Contract
Availability
- Product version
- Next Product release
- Licence
- An active Product licence is required except for health, authentication, and licence remediation operations.
- Entitlements
- workflow.enabled
- Service roles
- workflow
- Deployment
- customer managed installation
- Feature state
- preview
Security
Access
Sign in: Use a session cookie or Bearer session token.
- Actor
- Authenticated Pūnaha actor authorised for the selected tenant and resource
- Permission
- cases.manage
- Resource
- case_type / update / example casetypeid
- Tenant rule
- Tenant scoped unless the selected actor is performing an explicitly documented platform action. The x organization id header or authenticated session context selects the tenant. It does not grant access.
- Explicit deny
- An applicable explicit deny overrides an allow. Knowing or supplying a resource identifier never grants access.
Address, query and header fields
| Field | Location | Presence | Type | Meaning | Limits and example |
|---|---|---|---|---|---|
x-request-id | header | Optional | string | Optional caller supplied correlation identifier. Pūnaha returns the effective value in the response header. | Minimum length: 1. Maximum length: 200. Example: example request 001 |
caseTypeId | path | Required | string | The case type id that identifies the resource selected by this operation. | Minimum length: 1. Example: example casetypeid |
Request body
Content type: application/json. Presence: Required.
Operation request. Every property documents omission, null, sensitivity, source, mutability, availability, access, and lifecycle semantics through JSON Schema and x punaha-* annotations.
Request fields3 documented fields
Request fields
| Field | Presence | Type | Meaning | Empty and default | Limits and example | Access, sensitivity and lifecycle |
|---|---|---|---|---|---|---|
description | optional | string | Case type purpose and scope shown to users. | An empty string clears the description. Null is not a documented value. Default: Omission retains the current value. No client default is applied. | Example: Handles a fictitious customer complaint from intake to closure. | Changing this field requires the operation's exact update action. Inherits the operation availability. No special sensitivity is marked. Treat tenant authored text according to the tenant data classification and retention policy. Lifecycle: Next Product release. |
displayName | optional | string | Human readable case type name shown to users. | An empty or whitespace only value is ignored. Omit the field to retain the current name. Default: Omission retains the current value. No client default is applied. | Minimum length: 1. Example: Customer complaint | Changing this field requires the operation's exact update action. Inherits the operation availability. No special sensitivity is marked. Treat tenant authored text according to the tenant data classification and retention policy. Lifecycle: Next Product release. |
status | optional | one of draft, published, retired | Requested case type lifecycle state. | Omit the field to retain the current state. Empty and null values are ignored and should not be sent. Default: Omission retains the current value. No client default is applied. | Allowed: draft, published, retired. Example: published | Changing this field requires the operation's exact update action. Inherits the operation availability. No special sensitivity is marked. Treat tenant authored text according to the tenant data classification and retention policy. Lifecycle: Next Product release. |
Complete representative request using synthetic data
{
"description": "Handles a fictitious customer complaint from intake to closure.",
"displayName": "Customer complaint",
"status": "published"
}Smallest schema valid request
{}Responses
| Status | Meaning and correction boundary | Body |
|---|---|---|
200 | The operation completed and the response contains the current operation specific representation. | application/json, object |
400 | The operation failed with HTTP 400. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
401 | The operation failed with HTTP 401. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
402 | The operation failed with HTTP 402. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
403 | The operation failed with HTTP 403. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
404 | The operation failed with HTTP 404. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
409 | The operation failed with HTTP 409. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
423 | The operation failed with HTTP 423. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
500 | The operation failed with HTTP 500. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
503 | The operation failed with HTTP 503. Inspect error.code and error.details, apply the documented correction, and retain x request id. | application/json, APIError |
200 response fields1 documented field
200 response fields
| Field | Presence | Type | Meaning | Empty and default | Limits and example | Access, sensitivity and lifecycle |
|---|---|---|---|---|---|---|
data | required | JSON value | A JSON compatible value returned by this operation. | The field is present. Empty strings or collections are valid only when the field constraints and operation rules allow them. Default: No client default is assumed unless a JSON Schema default is present. | Example: example value | Inherits the operation access rules. Inherits the operation availability unless an operation specific rule says otherwise. No special sensitivity is marked. No special handling is inferred beyond normal tenant access, audit, retention, and data classification controls. Lifecycle: Next Product release. |
Successful response using synthetic data
{
"data": "example-value"
}Effects
Behaviour and other effects
- Changes
- Validates access and input, then applies the operation specific state change. A failed validation or authorisation check does not intentionally apply the requested change.
- Audit events
- case_type.updated
- Background work
- No background work is inferred. The success response represents completion of the HTTP action.
- External effects
- No external call is inferred from the route name. Operation specific service behaviour remains authoritative.
- Transaction boundary
- The HTTP success or error describes the synchronous boundary. Background operations have their own observable lifecycle and may outlive the request.
Operation
Reliability
- Idempotent
- No
- Retry
- Do not retry automatically after a timeout or lost response. Read current state first.
- Concurrency
- Use documented If Match or resource revision fields where exposed. Otherwise read current state before changing it and handle HTTP 409 conflicts.
- Consistency
- The response reflects the synchronous operation boundary. Background and provider backed state can converge later and must be read through its status operation.
- Timeout
- Client timeouts do not cancel completed or already started server work unless the operation explicitly supports cancellation.
- Request ID
- Send or record x request id and retain the returned value for diagnosis.
Errors and corrections
| Status | Code | Cause | Correction | Retryable | Partial work |
|---|---|---|---|---|---|
400 | INVALID_REQUEST_BODY | The request body or supplied field values are invalid. | Correct the named field or rule in error.details, then submit a new request. Retrying an unchanged request will not help. | No unchanged retry | No requested mutation is expected before this failure boundary. |
401 | AUTHENTICATION_REQUIRED | A valid authenticated session or supported token is required. | Authenticate again using a supported mechanism and confirm that the credential is current. | No unchanged retry | No requested mutation is expected before this failure boundary. |
402 | FEATURE_NOT_LICENSED | The active licence does not include a required entitlement. | Use an operation covered by the active entitlement or ask the System Owner to review the signed licence. | No unchanged retry | No requested mutation is expected before this failure boundary. |
403 | PERMISSION_REQUIRED | The authenticated actor does not have the exact permission or resource action. | Select the correct tenant and resource, then ask an authorised administrator to grant the exact documented action if appropriate. | No unchanged retry | No requested mutation is expected before this failure boundary. |
404 | NOT_FOUND | The selected resource does not exist in the authorised scope. | Obtain the identifier from the related list or create operation and confirm the selected tenant. | No unchanged retry | No requested mutation is expected before this failure boundary. |
409 | STATE_CONFLICT | Current resource state or a dependency prevents the requested change. | Read current state, resolve the named dependency or lifecycle conflict, and submit a deliberate new request. | No unchanged retry | The caller must read current resource or background operation state before retrying because work may have started before the failure became observable. |
423 | LICENCE_REMEDIATION_REQUIRED | The installation is restricted and permits only licence remediation actions. | Complete the indicated licence or membership remediation before retrying Product work. | No unchanged retry | The caller must read current resource or background operation state before retrying because work may have started before the failure became observable. |
500 | INTERNAL_ERROR | Pūnaha could not complete the operation because of an unexpected internal failure. | Retain x request id and the stable error code, avoid blind retries, and investigate the operation or contact support. Code: INTERNAL_ERROR. | No unchanged retry | The caller must read current resource or background operation state before retrying because work may have started before the failure became observable. |
503 | DEPENDENCY_UNAVAILABLE | A required node, database, provider, or service is temporarily unavailable. | Retain x request id, check health and the named dependency, then retry with bounded backoff when safe. | Yes, with the documented safeguards | The caller must read current resource or background operation state before retrying because work may have started before the failure became observable. |
Code examples
Use a supported credential and synthetic data. Do not disable TLS checks or retry a request that changes state blindly.
curl --request PATCH "$PUNAHA_URL/api/case-types/example-casetypeid" \
--header "Authorization: Bearer $PUNAHA_TOKEN" \
--header "x-request-id: example-request-001" \
--header "Content-Type: application/json" \
--data '{"description":"Handles a fictitious customer complaint from intake to closure.","displayName":"Customer complaint","status":"published"}'const response = await fetch(`${PUNAHA_URL}/api/case-types/example-casetypeid`, {
method: "PATCH",
headers: {
"x-request-id": "example-request-001",
"Authorization": "Bearer ${PUNAHA_TOKEN}",
"Content-Type": "application/json"
},
body: JSON.stringify({
"description": "Handles a fictitious customer complaint from intake to closure.",
"displayName": "Customer complaint",
"status": "published"
})
});
if (!response.ok) throw new Error(`Pūnaha request failed: ${response.status}`);
const result = response.status === 204 ? undefined : await response.json();using System.Net.Http.Headers;
using System.Text;
using var client = new HttpClient { BaseAddress = new Uri(punahaUrl) };
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", punahaToken);
using var request = new HttpRequestMessage(HttpMethod.Patch, "/api/case-types/example-casetypeid");
request.Headers.Add("x-request-id", "example-request-001");
var json = "{\"description\":\"Handles a fictitious customer complaint from intake to closure.\",\"displayName\":\"Customer complaint\",\"status\":\"published\"}";
request.Content = new StringContent(json, Encoding.UTF8, "application/json");
using var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();$headers = @{ Authorization = "Bearer $env:PUNAHA_TOKEN"; "x-request-id" = "example-request-001" }
$body = @'
{
"description": "Handles a fictitious customer complaint from intake to closure.",
"displayName": "Customer complaint",
"status": "published"
}
'@
Invoke-RestMethod -Method PATCH `
-Uri "$env:PUNAHA_URL/api/case-types/example-casetypeid" `
-Headers $headers `
-ContentType "application/json" `
-Body $bodyRelated APIs
deleteapiCaseTypesCaseTypeId, same domaingetapiCaseTypes, read or monitorgetapiCaseTypesCaseTypeId, read or monitorgetapiCaseTypesCaseTypeIdExportCmmn, read or monitorgetapiCaseTypesCaseTypeIdVersions, read or monitorpostapiCaseEvents, next action
Version history
- Next Product release: Operation documented from the current registered Go route and handler contract.
Was this page helpful?
Your answer helps us improve the documentation.
Do not include personal information, customer information, passwords, or keys.