Problem
Setting list-type custom attributes on tickets via the API is painful enough that our engineering team now recommends against using list attributes — even when they'd be the better UX for our agents.
Specifically, the issues that lead us to this recommendation are:
1. Read/write asymmetry. Intercom returns the display label on read, but rejects that same label on write and requires an internal UUID. Round-tripping a value we just received does not work.
2. UUIDs aren't exposed in the UI. The only way to obtain them is to make a specific API query — there's no admin screen or export.
3. UUIDs differ between sandbox and production. Every list option must be re-discovered and re-mapped per environment; no config promotion path exists.
4. Downstream cost. We now maintain one ENV var per list option per environment, just to translate stable concepts onto volatile UUIDs. The maintenance burden is steering us away from the feature entirely.
Suggested fixes (any one would help; together they'd align with API conventions):
1. Accept the display label on write, rejecting with a clear error on ambiguity.
2. Support customer-defined stable keys per option (e.g. Stripe's lookup_key, Salesforce API names) so the same identifier works across workspaces.
3. Expose UUIDs in the attribute admin UI, copyable.