Here's another use-case you appear not to have considered. Our client manages different lists across their various teams, and different pages where they might want to display simple signup forms for those lists.
In our backend UI for managing the pages, we want to allow the client to configure a signup form for a given List. We take care of making sure signups through that form get to the right place through API calls and such, but we don't want our non-techie client to have to know anything about APIs, JSON, or any of that. We certainly don't want them to have to muck around in Dev Tools. For our client to have to come to us every time they want to create a signup form for a List they don't have one for yet (not to mention us having to reread the docs and make an API call inside a specialized tool, having forgotten since the last time we did it) creates a bottleneck, and a rather tedious experience overall.
So while it's true that it's "only for use with the API," that is not a reason to only expose it to developers.
Adding the ID to the UI addresses all of this quite simply. Until you add it back there's not really a good solution for this use-case.
The best case scenario is that a developer would put in their UI a way for their users to select the list for the sign-up form. This is how the API is intended for use.
In your example you as the developer would make the API call to retrieve the customer's lists and then display them in your backend UI using perhaps a drop down menu, radio buttons, or whatever display method you chose.
Then your customer uses your UI to create their sign-up form and when it comes time to select the list they have the lists from their Constant Contact account already displaying and ready for them to select. For example here is a screenshot from our own first party integration for WordPress plugin which uses the v2 API.
We are not against discussing other use cases and potentially making changes. At this time I'm just wondering why an integration would not offer the lists in the UI versus making the customer go anywhere to get the listID, even if that is asking the customer to log in to the Constant Contact website?
Thanks for responding.
> At this time I'm just wondering why an integration would not offer the lists in the UI versus making the customer go anywhere to get the listID, even if that is asking the customer to log in to the Constant Contact website?
Because we have a limited budget, and more important problems to solve for our client than a bespoke UI for picking List IDs, if we can accomplish the same by asking the client to copy and paste a number.
But, it seems you are saying that it is always preferable to build a UI and not even give the client the option to copy that number over, even if it costs them less to develop.