POST /v1/jobs/{jobId}/plate
Save wells on a job's plate
ivy_ API key (Authorization: Bearer ivy_… or X-Ivy-Api-Key), a Clerk session JWT (Authorization: Bearer …) or the Clerk __session cookie (browser sessions). See Authentication.Saves one or more wells on a job you can write to. Each update is keyed by row and col: an existing well at that position is replaced, otherwise it is created. The well name is derived from row and col when you do not send well.
If you send compound_smiles without compound_id, the SMILES is resolved to a molecule id, which is stored on the well and linked to the job. If you do not send concentration_uM, it is computed as stock_uM divided by dilution_ratio when both are present and dilution_ratio is above zero. Updates whose row or col is not a finite number are dropped.
After saving, the route refreshes the job's rollups and appends a plate-update event with the previous and new values to the job's manifest. Both steps are best effort: manifestEventWritten tells you whether the manifest event was written, and a failure in either does not fail the request. A project viewer can read a plate but not save it; saving returns 404 for them.
Request
Path parameters
UUID of the job.
Request body
Wells to save. Must contain at least one entry with a numeric row and col.
Example
Responses
200 OK
Response shape:
Number of wells saved.
Whether the plate-update event was appended to the job's manifest. The wells are saved either way.
400 Bad Request
code is VALIDATION_ERROR and details.issues lists the problems); updates is empty; or no update has a numeric row and colResponse shape: object
401 Unauthorized
Response shape: object
404 Not Found
Response shape: object
429 Too Many Requests
Response shape: object
500 Internal Server Error
Response shape: object
Was this page helpful?