Is there a current working solution for accessing appointments via API with a Service Account Key? It appears the REST v1 is bugged (?), XML-RPC is depreciated, and I’m getting 500 responses from REST v2 with a SAK. Any advice/direction would be greatly appreciated.
Welcome @Jeff_Santoro ,
REST v2 is not complete, and I do not see the Appointment Endpoint yet.
As for REST v1, there are bugs, but unsure if Keap are planning to fix them given that v2 supersedes it.
@OmarAlmonte can give more response about REST, but you will need to explain what the issue you are getting.
You can still use the XML-RPC API, the Appointments are available via the “ContactAction” table.
https://developer.infusionsoft.com/docs/table-schema/#ContactAction
The Service Account Key will work for the REST and XML-RPC API.
Thanks Pav!
This is the response I’m getting from the XML-RPC using a SAK.
XML-RPC: faultCode16faultString[DisallowedAuthenticationType]This form of authentication is no longer allowed (Please see our developer site for additional information on this deprecation: Legacy Key Deprecation - Keap Developer Portal)
Given your response, I’m thinking this is likely a call error on my part. Thoughts?
I am taking a guess that you maybe using an old SDK?
The Legacy API Key was deprecated last year, but developers had to either update to newer SDKs, or alter the HTTP Header to connect to it.
In the API Request part of your code, make sure the HTTP Header has the following where the Token (without the <>) is your SAK.
Authorization: Bearer <TOKEN>
eg: Authorization: Bearer 1234567890ABCDEF
See if that works.
1 Like
It’s a new SDK, just made it a couple months ago. Here’s the XML I’m sending in now. I didn’t have the authentication in the header before. Still no luck. Does the endpoint require the app name now as well? Thank you very much for the help with this.
POST /crm/xmlrpc/v1 HTTP/1.0
Authorization: Bearer KeapAK-TheToken
Host: api.infusionsoft.com
Content-Type: text/xml
User-Agent: The Incutio XML-RPC PHP Library
Content-Length: 424
Forgot to say, make sure the API URL is the following below.
https://api.infusionsoft.com/crm/xmlrpc
Originally it was this before “https://.infusionsoft.com/api/xmlrpc”.
Ignore me, I see you already set it, was looking at how the code was doing it.
Taking a look online, I see you are using this library below, based on the User Agent name.
It is 6 years old, but it is now out of date and needs changes done to it.
If you made the necessary changes with the connection part, it should technically work. Although, I never used the SDK so cannot comment on how good it is.
I bet there is something simple in your code, or maybe the XML is the issue. To post code in the forum use the preformatted text button in the editor, or enter three back facing apostrophes ( ` ).
1 Like
Hello everyone,
CC: @Jeff_Santoro
The v1 appointments endpoint works with OAuth tokens and PATs, returning all appointments as expected. With Service Account Keys (SAKs), it currently returns an empty list. GET v1/appointments/{id} still returns data if the appointment exists, same for tasks.
Internally, for this particular endpoint, SAKs don’t have any user context, which is why the list is empty. Using a PAT or OAuth token will return the appointments as expected until our new appointments APIs are released.
You nailed it with the library being the issue. Thanks! I’m moving forward again witht he authentication in the header and “manually” building the XML.
@OmarAlmonte, what a bizarre implementation that was done there. In XML-RPC we have full access to the appointments, so I would have expected the same in REST v1 under the SAK key as well.
Is it just Appointments that are limited to the user context?
Will the REST v2 Appointment Endpoint resolve the issue?
1 Like
If someone else is reading this with a similar issue, the API also needed to be a normal XML param, so it’s being sent twice. Once in the header and again as a param.
Tasks are also scoped to the user context. As for the v2 Appointments endpoint, there is planned work and the exact behavior is not finalized yet. For more details, refer to: https://learn.thryv.com/hc/en-us/articles/40566846578573-XMLRPC-Endpoints-Not-Being-Converted-to-REST-v2
Due to the Legacy API Key requiring it in the XML before. That can be set to blank if you want.
Is there any official plan for Appointments yet? I got the notice about the one year timeline and I don’t see anything in the mapping xls linked in the article provided. Would the most straight forward solution be to try and upgrade everything to oAuth at this point?
@Jeff_Santoro At the moment we don’t have any additional updates to share regarding Appointments. The team will communicate more details once there’s new information available.
Regarding authentication, REST v2 supports PATs, SAKs, and OAuth. You can refer to the documentation here for OAuth and here for PATs and SAKs. The respective use cases for each option are explained in the documentation.
Just to confirm, are you not seeing the file at all, or you don’t see anything specifically related to Appointments in the mapping sheet?
I got the mapping sheet up and loaded just fine. I’m not seeing anything related to appointment objects… only tasks.
Got it, for appointments there is planned work and the exact behavior is not finalized yet, the team will communicate more details once there’s new information available.