_id. The request body is dispatched by the type discriminator, which must match the configured answer type. There is no POST/DELETE: the answer set is fixed by the inspection template.numericValue (send null to clear). Out-of-norm values are accepted (warning is a client concern).textValue (send null to clear).selectedOption.selectedOptionIds (single id unless the answer is multiselect).isApplicable). Optional on every type, and orthogonal to the value: false marks the answer Not applicable, true brings it back. The stored value is never cleared by the flag — clients hide it while the answer is N/A. Because the value fields are optional, an offline client can send the flag together with its last known value in a single request.ComplianceAnswerOption.NOT_APPLICABLE no longer exists — N/A is only this flag. The string NOT_APPLICABLE survives solely as a summary bucket in the PDF report, not as a selectable option.PUT /project/{projectId}/inspection/{inspectionId}/section/{sectionId}/answers/batch.curl --location --globoff --request PUT 'https://app.hustro.com/api/v2/project//inspection//protocolItem//answer/{{protocolAnswerId}}' \
--header 'hustro-client: web' \
--header 'hustro-client-version: ' \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '{
"type": "NUMERIC",
"numericValue": 5
}'{
"_id": "5f479169f7ef7fe33b3cca36",
"checklistAnswerId": "5f479169f7ef7fe33b3cca36",
"type": "COMPLIANCE",
"isApplicable": true,
"selectedOption": "PASSED"
}