We are in the process of upgrading one of our applications that was using an older method for accessing your API. I was successful is upgrading to use OAuth2 and everything is working.
My issue is, when I attempt to test access by a user that may have changed their username on your system, but not in my app, I get a horrible "HTTP 403" error.
My question is, do we have a more graceful way to report errors?
I would like to use the PHP library for CTCT-OAuth2 without having to modify it (if possible)
Please advise. Thanks in advance!
Sorry, but our standard error messaging and PHP wrapper is all that we have available on our side. We are working on better error messaging in the future. If you would like to provide better messaging to your users, you would need to check for a 403 and then return 'prettier' error messaging to them on your side.
API Support Specialist
Thanks for this information, although it's not what I was hoping for ;-)
On another note:
Do you have an update on the new API v2? I was part of the beta program, but it seems that everything went the way of the DoDo, since I haven't heard anything in months.
I am still waiting for a PHP library that was promised in September (or so).
Thanks again for the information!
Yes, we are still working on version 2 of our API--we just don't have a lot new to report on that front. Engineers are hard at work building features into it. We hope to be going live with it, and have wrappers for it, in the first or second quarter of next year (but that is subject to change, as always).
API Support Specialist
Hey Bob - API is still in development and we're still on track for releasing early next year. Beta is still available to use if you want, the information for accessing it hasn't changed. We did take your feedback on the wrapper libraries very seriously and it's on our roadmap to provide for the launch. Since the API feature set isn't finalized and we're still updating response data and URIs, we haven't started working on the wrappers. It would end up adding a ton of additional work to keep updating a wrapper whenever we update the API formats.
Thanks for the follow up!
Totally understood, however now it seems this new information is different from what I was lead to believe.
I kept being told that PHP wrappers were in the works and should be available (before launch).
Might be helpful to announce that sooner and even a requirement to be a part of the beta.
(PHP not being available that is)
If I am not mistaken, you are saying that I am not able to work with the beta, UNLESS I can use it with one of the available wrappers, like Ruby. Is that correct?
The code we provided for beta was just automated class object models that we created through our builds to help speed up time for developers, there was no work required for us to build those. Also, it didn't actually do any of the work, such as serializing the data, forming the requests or handling OAuth 2.0. Unfortunately, the tool we used to generate those automated object models didn't have PHP as one of the supported languages. In order to have PHP objects generated automatically with each build, we would have had to write a new library for the tool we used to add PHP to the list of languages it supported.
Instead, we decided to create full wrapper libraries that handle OAuth 2.0, serialization, request URIs and object models as part of our launch. This will be a much more complete experience and help developers get up and running much faster. Becaues it's also a much larger task, and one we can't automate through any open source libraries, we're going to develop it by hand and host it on github for anyone to use.
Sorry for any miscommuications on the calls. We do indeed want to have PHP wrappers available at launch. In fact, it's the first library we plan on writing. This wouldn't proclude you from using the beta endpoints. PHP actually has a very simple option to get around this limitation that you can use if you'd like to try out the new endpoints. Using this PHP method, you can serialize any JSON object into a PHP object: json_decode(). All you need to do to get an object of one of our API responses is to pass in the response JSON to that method and you'll receive an object back. No wrapper needed. While it won't be serialied into a pre-formed object, it will be correctly returned into a complete, dynamic object.