I am calling it but it is not returning any records. I have tried using the contact_id paramater as well as the since and I don’t get any records. Thank you
I have the same issue.
I just reproduced the issue and it definitely looks like something’s broken with the Task service; I’ve ticketed it to the appropriate team and asked them to get it prioritized for a fix.
Thank you for bringing it to our attention!
Thank you Branson for chiming in and thank you Tom for checking into it! Appreciate it!
So I got some feedback from our dev team that was looking at it, apparently this is one of the older (and weirder) ones that doesn’t really conform to our current standards. If you just query the endpoint you only see your own Tasks, and it works fine for that case if you happen to be using a Personal Access Token. However, if you authorize a Service Account Key it isn’t acting under your own authority, but that of the system, and the system doesn’t have Tasks assigned to it so nothing comes back.
However, there is a workaround until we get the v2 Tasks endpoint out: you can supply a ?user_id=
filter onto the call and it will return that user’s Tasks. You can query /users
once to get a list of the UserIds, then fire off several /tasks
calls to collect the results.
Thank you Tom for the information. I was trying to get away from the looping through UserIds to get tasks as that takes a very long time. What about the XML-RPC API, could I perform a query and return all tasks for a certain date range or that have been modified? If so, can I do the same thing for payments?
Thank you
Tom, I re-read your response and I realized you were talking about User_ids and not Contact Ids which made it much more feasible and I was able to loop through the UserIds relatively quickly.
Does the Appointment API work? I tried the same approach with it and I can’t return any records. The only way I can get an appointment back is if I specify and Appointment Id. I tried using Contact and User Ids and it returned nothing.
Thanks again
After some digging the /v1/appointments list retrieves records assigned to the authenticated user, which is relevant only to Personal Access Tokens and to OAuth2 Access Code authorizations. Service Account Key and Legacy Key API key authentication would return no values.