• State Verified Answer
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 2 subscribers
  • Views 8 views
  • Users 0 members are here
Options
Related

Create work order and assign technician in single API call?

Devon Marsh

Hey folks — working on an integration where we're creating work orders from an external scheduling system. Right now I'm making two calls: POST to /work_orders to create, then PATCH to update the assignee_id.

Wondering if there's a way to do this in one shot? I tried including assignee_id in the POST body but got a 422 with "assignee cannot be set during creation."

Is this a hard limitation or am I missing something in the payload structure? Would be nice to cut the round-trip latency here.

cc similar OAuth question for context on how I'm authenticating these calls.

  • 0

    Current API behavior: assignee_id is ignored on POST. Required fields for creation: title, customer_id.

    • Workaround: POST then PATCH (your current approach)
    • Alternative: Use /work_orders/bulk endpoint — supports nested operations

    Required fields reference

    Known limitation tracked internally. No ETA.

  • 0

    Hey Devon — yeah this trips people up. The short answer is Leo's right: standard POST doesn't support it, but the bulk endpoint does let you bundle operations.

    Here's what that looks like:

    POST /v1/work_orders/bulk
{
  "operations": [
    {
      "method": "POST",
      "path": "/work_orders",
      "body": {
        "title": "HVAC Maintenance",
        "customer_id": "cust_abc123"
      }
    },
    {
      "method": "PATCH",
      "path": "/work_orders/{id_from_first_response}",
      "body": {
        "assignee_id": "usr_def456"
      }
    }
  ]
}

    It's technically still two operations, but single HTTP round-trip. The responses come back in order so you can correlate.

    Heads up: bulk endpoint has different rate limits — 10 ops per request, 100 requests/minute vs the standard 1000/min for individual calls. YMMV depending on your volume.

    There's also a webhook work_order.created you could listen for and assign reactively, but that adds complexity vs. just accepting the two-step flow.

    I've flagged this with the API team — nested resource creation on POST comes up a lot. No committed timeline but it's on the radar.

  • 0 in reply to Eli Torres (Staff)

    Perfect — the bulk endpoint approach works for my use case. I can live with 10 ops per request, we're not that high volume.

    One follow-up: is the response order guaranteed even if the second operation fails? i.e. will I always get the work order ID in the first response slot?

  • 0 in reply to Devon Marsh

    Yep, guaranteed order. Even on partial failure you'll get responses[i] matching operations[i]. Check the status field on each — can be 201, 200, 4xx, 5xx independently.

    Pro tip: enable the Prefer: return=representation header to get full object bodies back, not just status codes. Makes the response parsing way cleaner.

  • 0 
    // Another approach — async assignment via webhook handler
// We do this for ~5k jobs/day, works fine

app.post('/webhooks/work_order.created', async (req, res) => {
  const { work_order_id } = req.body;
  const assignee = await calculateAssignee(work_order_id);
  await fp.patch(`/work_orders/${work_order_id}`, { assignee_id: assignee });
  res.sendStatus(200);
});

    Latency is higher but you get to implement your own assignment logic. We found the 200ms extra per job worth it for load balancing across techs.