API returning 500 on nested custom field expansion

Hey Carlos — yeah this one tripped me up too when I first looked at it. The expansion syntax changed slightly in v1.2 and the error message is... not helpful.

The issue is that custom_fields isn't a relationship you can traverse with dot notation. It's a flat object on the work order itself. Try:

GET /v1/work_orders?expand=custom_fields&limit=50

That'll give you the full custom_fields blob with all values. If you need specific field filtering, that's a separate custom_field_ids query param (undocumented, I know — we're fixing that).

The 500 is a bug on our end — should be 400 with a clear message. Filed ts-034 to track.

Re: your failing requests — I can see those in the logs. The parser is choking on the dot notation and falling through to a generic error handler. Working on a fix for next deploy.

Confirmed — expand=custom_fields works. Returns everything though, which is heavy.

custom_field_ids param — what's the format? comma-separated? array syntax?

Comma-separated string:

GET /v1/work_orders?expand=custom_fields&custom_field_ids=cf_123,cf_456&limit=50

You'll still need expand=custom_fields — the filter just limits which keys come back in that object.

Heads up: custom_field_ids without expand=custom_fields is silently ignored right now. Another rough edge for the cleanup list.

Docs are wrong here: help-055 shows dot notation for custom field expansion. Should be deprecated or corrected.

Also — expand=custom_fields.customer_preferences was valid in v1.0-v1.1. Breaking change not listed in news-025.

Good catch Leo — you're right on both. The v1.0 nested expansion was a side effect of how we serialized, not intentional API design. When we fixed the serialization bug, the dots stopped working.

I'll get the changelog updated and flag help-055 for a rewrite. Appreciate the sharp eye.

Running into something similar. custom_field_ids filter works, but there's a gotcha with deleted fields — if you include a deleted field ID, the whole request 500s instead of returning null or omitting it.

Workaround is to fetch /v1/custom_fields first and validate IDs against active ones. YMMV.

Can confirm — reproduced with deleted field cf_789:

GET /v1/work_orders?expand=custom_fields&custom_field_ids=cf_123,cf_789
cf_789 deleted 3 days ago

500 response, request_id req_2f5a8c9e4d1b

Added to the same ticket — this is clearly a validation gap across the custom field expansion path. We're going to tighten this up to return 400 with explicit error context rather than these opaque 500s.

For now I'd recommend the workaround Devon mentioned, or just expanding without filtering if your payload sizes are manageable.