Skip to main content

Save draft edits to validation-failed roster rows

PATCH 
/roster-records/:rosterId/draft

Applies corrections to a batch of roster rows and stores them as an in-progress draft.

When to use: call this after reviewing validation errors, to record proposed fixes before asking for the roster to be checked again; follow it with POST /roster-records/{rosterId}/revalidate when the corrections are ready to be re-run.

Preconditions: supply the tenant-id header and the rosterId of an existing roster job. Only rows currently in VALIDATION_FAILED or VALIDATED_WITH_WARNINGS state can be drafted; every entry in rows must set recordKey to the rowId of a row in that roster, obtained from the roster row listing endpoints. Each entry's rowData is merged into the stored row one level deep - top-level keys you supply replace their stored counterparts, keys you omit are left untouched, and nested objects are replaced wholesale rather than merged. The batch is limited to 100 entries by default; a larger batch is rejected with 400 and should be split.

Partial success: entries are processed individually, so one bad entry does not discard the rest. An entry is reported as a failure - and the others still saved - when its recordKey matches no row in the roster, when its rowData is not a JSON object, or when the target row is not in VALIDATION_FAILED or VALIDATED_WITH_WARNINGS state. Always read failures in the response rather than relying on the HTTP status alone. What you get back: succeeded, the number of rows saved, and failures, one entry per rejected row with the recordKey and the reason.

Side effects: each saved row is marked as drafted and its payload is appended to that row's draft history, so this operation is not idempotent - submitting identical edits twice appends two history entries. Row status is set to VALIDATION_FAILED for every drafted row, including one that was VALIDATED_WITH_WARNINGS: an edited row has not been validated, so it is held out of the import until you call the revalidate endpoint.

Request​

Responses​

The outcome of the batch: how many rows were saved, and one entry per row that was rejected. A non-empty failures list can accompany a successful response.