Hello,
I see the REST API doesn’t appear to support GET
on /tags/categories
.
Is the best way to get a list of tag categories to hit GET
/tags
and then map the unique category objects?
Thanks a lot!
Hello,
I see the REST API doesn’t appear to support GET
on /tags/categories
.
Is the best way to get a list of tag categories to hit GET
/tags
and then map the unique category objects?
Thanks a lot!
Hi @Roy_McKenzie,
At this time there is not a way to retrieve already existing tag categories in REST (you can add a category and get the id from the response body). In an earlier post it was recommended to use the xmlrpc api to query the ContactGroupCategory table to retrieve the category info. The team has a ticket for this feature for future work but do not have an ETA as of yet.
Thanks Carlos! Since the category info is available on the category object in the tag object I think it makes more sense to still use the REST API, fetch all the tags, and map the unique categories. I’ll leave this specific question unsolved until there’s a RESTful solution.
Thanks!
It is a temporary condition as REST is still in development. You can use the same OAuth access token with the XML-RPC to grab the categories in the mean time and then just change that one function when updates to REST include categories.
No thanks! There is no guarantee that the XML-RPC response will be the same as the REST response when it is finally implemented. If the XML-RPC API gets sunsetted before my code is updated, then the code will break. I will be staying away from XML-RPC as it is referred to as “legacy” in some places in the Infusionsoft docs.
lol ok
Talk of sunsetting has gone on for over 4 years and IS has committed to giving ample notice when that decision has been made…it has not been made and it would be in the line of 6 mo to a year to prepare…setting one function up with it would be an easy transition as it still uses the same access token as REST does… kinda a mountain out of a mole hill but whatever your preferences are, are certainly up to you… just giving you options
I am not sure who will be maintaining my code in the future. This seems like the most future-proof way. So again, no thanks!