POST /entity/_batch

Params

Sample requests

r = c.post("/entity/_batch", json={"requests": [
    {"request_type": "create", "entity": "Shot",
     "data": {"project": {"type": "Project", "id": 1180}, "code": "sh010"}},
    {"request_type": "update", "entity": "Shot", "record_id": 7652,
     "data": {"description": "batched"}}]})

One envelope per request, each wrapping its own data. The nesting is one level deeper than a single-row create:

{
  "data": [
    { "data": { "type": "Shot",
                "attributes": { "code": "sh010", "sg_status_list": "wtg" },
                "id": 7654 } },
    { "data": { "type": "Shot", "attributes": { "description": "batched" }, "id": 7652 } }
  ]
}

Sending the list under data, which is the key the response uses:

{"errors": [{"status": 400, "code": 103, "title": "Request Parameters invalid.",
             "source": {"requests": ["requests is missing"]}}]}

One bad request in an otherwise good batch:

r = c.post("/entity/_batch", json={"requests": [
    {"request_type": "create", "entity": "Shot",
     "data": {"project": {"type": "Project", "id": 1180}, "code": "sh011"}},
    {"request_type": "update", "entity": "Shot", "record_id": 999999999, "data": {"description": "x"}}]})
print(r.status_code)   # 404
# and afterwards, searching for sh011 returns 0 rows

Response codes

Edge cases

• It is atomic. The Shot the first request would have created does not exist after the 404.
• The response nesting is the trap that outlives a run. Reading row["id"] instead of row["data"]["id"] yields None, so cleanup silently skips the rows and they stay on the site.
• A returned id does not by itself prove the row exists. Read back after a batch that matters.
• The request key and the response key differ by name. requests in, data out.