Howdy! Thanks for reporting this!
We are in the process of refactoring many of the non-public APIs into stable v1 endpoints. Unfortunately we do not have an ETA for when these APIs will land. However, we are reluctant to document and standardize these other / undocumented API endpoints since it would potentially give false impressions around our attachment to these APIs.
Currently, these undocumented APIs are considered "experimental," and we expect them to change across Connect releases. The reason we have included them in the
connectapi package is that we can
- warn about the status of the API when used
- try to maintain backwards compatibility in the client library (i.e. release a new version of
connectapi that switch to the new APIs w/ minimal customer impact)
- when backwards compatibility is not possible, we can warn about changes across
If you are interested in seeing the current state of affairs, you can use this article on our
Our goal is definitely to remove these weird undocumented endpoints. However, the current plan is to be mostly by replacing with new APIs rather than formalizing APIs with known faults
What primarily draws you to the need for documentation? Are you using another language or scripting mechanism for calling Connect APIs?