Skip to main content

Finalise a deposit

POST 
/deposit/:id/finalise

Optional core — provided when deposit.supported is true. See the Deposits guide.

Finalise the deposit: validate the staged content, publish it as the RO-Crate's new current version (replacing the prior version wholesale), and materialise catalog entities from it. Validation depth and materialisation rules are implementation-defined.

Finalisation MAY complete synchronously or asynchronously, at the server's discretion per request — there is no capability flag. A 200 returns the deposit in state complete; a 202 returns it in state finalising, and the client polls GET /deposit/{id} until the state leaves finalising. One client code path handles both.

For every file staged in presigned mode, finalise verifies the bytes landed and match the declared size and checksum; missing or mismatched files are validation violations.

Failure atomicity is guaranteed: a finalise that does not reach complete leaves no observable change. On validation failure the deposit returns to open with the violations recorded — as a 422 on the synchronous path, and in the deposit's errors field on the asynchronous path. Non-validation failures (including the target RO-Crate having been deleted mid-deposit) also return the deposit to open with the failure recorded; retry is safe, and abort covers walking away. Once complete, the new metadata document and all materialised entities are readable; readers are not guaranteed to observe the transition as a single atomic flip.

For update deposits, carry-forward resolves against the baseline version pinned when the deposit was opened; the last finalise wins as a unit. Implementations MAY reject a finalise whose baseline has been superseded with 409.

Request​

Responses​

Finalised synchronously - the deposit is complete and the RO-Crate's new version is published