The data from webhooks and the Favro API do not provide any mechanism to narrow scope of Custom Fields, e.g. to determine which are associated with a given Collection or Widget.

A complex organization can have an enormous number of Custom Fields (we just started using Favro 2 weeks ago, and already have >200). A huge fraction of those have non-unique names (e.g. "Status").

When a card already has fields set, this isn't a problem since it's easy to look up a Custom Field's information given its ID.

However, when a card does not have a field set we have no mechanisms by which to infer which Custom Field ID is the one we want.

The use case for this is to allow programmatic discovery of appropriate Custom Fields (like collection or widget, since via the App Custom Fields are treated as if scoped that way).

This would allow for creation of cards and updating of fields from external tools (via the API), without a developer having to hard-code identifiers.

This would also allow automatic discovery when things change, for example allowing App users to add new fields that could be immediately used by an external tool without having to again go discover and then hard-code Custom Field IDs.

It looks like Custom Field IDs are only discoverable via the API/webhook data (which are difficult to use to confidently find the right ID), or via browser dev tools by inspecting the HTML element.

If the app's HTML will always include the Custom Field IDs baked in, then this is an OK solution to the discovery part of the problem. Better would be some setting that displays them in the app's UI.

Both of the following features would be very helpful in this regard: