We're building automated lead intake against your REST API (api.leadsimple.com/rest) and hit a gap we'd like to request parity on.

The request: Allow setting user roles on deals via the API, the same way it already works for processes.

What works today: POST /processes and PUT /processes/{id} accept users_in_roles[][role_id] and users_in_roles[][user_id], and role definitions are discoverable via GET /process_types/{id}/assignee_roles. This works great.

The gap: Deals have no equivalent, even though pipelines support the same user roles in the UI (Pipeline Settings → Users & Roles → Add Assignee Role). Specifically:

POST /deals and PUT /deals/{deal_id} accept only assignee_id (the Lead Owner). Passing users_in_roles[][role_id] / users_in_roles[][user_id] with valid UUIDs returns 200 but the parameter is silently ignored — no role is assigned and no error is returned.

The Deal object in API responses doesn't include user role assignments at all, so they can't be read back either.

There's no GET /pipelines/{id}/assignee_roles endpoint to discover which roles a pipeline uses (the process-type equivalent exists).

Our use case: We create and update leads in our Landlords pipeline programmatically from our website and phone intake systems. That pipeline has a "Leasing Manager" user role that drives who works the lead, and today it can only be set by hand in the UI. Since roles are global objects shared between pipelines and process types, extending the existing users_in_roles parameter to the deal endpoints would give full parity with what the UI already supports.

Requested changes, in priority order:

Accept users_in_roles on POST /deals and PUT /deals/{deal_id} (or return a validation error rather than silently dropping it).

Include user role assignments in the Deal response body.

Add GET /pipelines/{pipeline_id}/assignee_roles.

Happy to provide request/response examples from our testing if useful. Thanks for considering it!