With the launch of our new GraphQL API we will be deprecating our existing API.
The anticipated date for deprecation is July, 31st 2020.
What does that mean for you?
If you are just starting out using the ShipHero API, use the GraphQL API instead.
If you have already used the legacy API, start thinking about porting over to the GraphQL API. It’s more powerful, gives you greater access to information and we’re going to be building some awesome things into the new API.
We won’t be adding new features to the legacy API
Webhooks and related endpoints are not yet slated for deprecation as a GraphQL replacement has not been implemented yet.
We’re working with the GaphQL API to Create Orders and using Webhooks to receive order updates.
We have however run into some confusion with our clients about the different authentication methods for the GraphQL API and the Webhooks.
GraphQL requires username and password
Webhooks requires API keys
Problems
Our client is confused why we need both username and password and API keys
Changing the user password for access to the GraphQL API will break the integration
While I agree that the GraphQL API is good for querying data, it doesnt seem efficient for platforms to integrate to create orders and receive updates give we need multiple authentication credentials to do so. We’d much prefer to use the REST api to create orders and receive Webhooks that also follow REST principles.
Yes, we are still planning on deprecating the Rest API but Webhooks will still be available.
Both Rest API and Webhooks work with API Keys because they use the legacy code, but for the new GraphQL API we have a new authentication strategy, and this consists of a Token which pretty much works as an API key:
You’ll have to generate it once, using your username and password
It expires every month
We plan on migrating Webhooks as well eventually, but this does not have an ETA and will not be developed any time soon.
Let me know if there’s anything else I can help you with.
Thanks!
Tom
Thanks, this is what we have built (GraphQL + Webhooks aka REST) but I think you missed my point. I’m working with one of your clients and it took 3 times for them to understand that I needed an API user login AND API Keys in order to use both the GrapQL API for sending orders and Webhooks to receive order updates.
As a 3rd party “integrator” into your platform and needing to explain this to your clients this is quite confusing to them. Even mildly technical savvy client just see API keys and think, oh this is all they need but it’s not.
Also, most other companies that have GraphQL APIs did not deprecate their REST API to give developers options when building integrations. Completely removing the REST API doesn’t make a lot of sense.
What may be nice here is an accessible way for clients to generate an access token and refresh token for integrators, once you have that you don’t need access to the account login info so there’s likely no need to create a separate api user.
Depending upon the implementation it could also make sense to create an interface for clients to plug in their API credentials and/or generate GraphQL tokens using their login info, that should be possible already from what I gather.
The problem here is that requiring the client to give us their ShipHero username and password defeats the purpose of having API keys. All security has now been lost. There needs to be a way to get the API key without the client having to provide us their login details. Either via a true OAuth flow or via the user collecting this information from inside their account.
Hi @alex29next@williamw@originsid
I apologize for the delay in my response here. I will take all of this feedback and engage our engineers about this. This way, I can bring more insight into this and possible solutions/workarounds to what you are trying to accomplish.
I appreciate your patience in this.
Thanks again,
Tom
Thanks Tom. Ideally we could continue to use the Rest API endpoints for the foreseeable future. With that we would only need the API key and would greatly simplify our integration and communication to our clients about what access credentials we need to configure in their ecom store for their shiphero integration.
We need to know, if the old API will stop working. If that is the case, how on earth shall I explain to my client, that we need to recode their integration to you!?
Hello! I also would like to know if REST will continue to work after deprecation. I also would like to know how this will affect Magento 1 integrations such as ours… will we be able to continue using ShipHero after deprecation? Customer service has already let me know that Magento 1 is no longer supported, and I get that… but updating to Magento 2 in 3 months just isn’t going to happen.
Hello engineers! We really need some insight into the REST API deprecation situation. We have an entire system built on the REST API that basically runs our company. The fact that we will now have to spend thousands of dollars and many man hours to have that entire system recreated on the new API is pretty disappointing. There are many valid points above as to why it should be kept. We are working on adding features to our current platform and without knowing what is going to happen to the REST API we are at a standstill. Any information would be much appreciated.
Rest API will be deprecated on July 31st, meaning it will no longer be available for making requests (In case it helps we have a section that will guide you through what queries/mutations you need to look at when replacing the REST API with the GraphQL API)
Webhooks will continue to work like they are until further notice.
Registration will be available (No ETA yet though) that will enable users to give consent for 3rd party apps that will automatically create a user on the Client’s account for the 3rd party app to make requests.
For number 2 we don’t have an ETA on when they will be ported to the GraphQL API, when it does we will make the anouncement and give time for users to migrate or make necessary adjustments.
As for number 3, the idea behind is that everything would be done through public API by the 3rd party devs (creating the dev account, registering the 3rd party app, hitting a mutation to generate the authorization URL they have to give their customers to get their consent) and this is being worked on, so it will be available in the short term.
I will let you know as soon as possible when we have this ready.
I appreciate all of your patience and understanding on this,
Tom
I am gonna be honest looking at the latest topics doesn’t have me thrilled about this decision but ok. I guess I will get to it and start paying a developer to rewrite the whole Shiphero SDK, it’s not like he just finished this project for us and now has to start over. The inconvenience of him rewriting it in Graphql better have some amazing benefits. Deep down in my gut, I have a feeling that this is going to be quite the nightmare, and seeing the topics on this forum doesn’t really give me any reassurance. Good luck to everyone else who is in the same boat especially the ones who have to now tell their clients that it’s going to cost more to make this transition. I understand businesses have to make tough decisions but this seems to alienate the user base who put in hundreds of hours of work without even asking if this is the correct move.
Hi Tom. Thank you for the reply. This is really quite disappointing. Frankly, we will look into various solutions, and leaving ShipHero will be one of them.
Just to be clear: for those clients using REST and Magento 1, the only available solutions are to upgrade to Magento 2 + GraphQL within July 31st or stop using ShipHero entirely. Correct?
I just want to provide a little hope to anyone considering the GraphQL implementation.
We’ve successfully written a few simple python scripts that sync orders, line items, and returns into google sheets and keep those data in sync as orders are updated, and the only real difficulty we had was unexpected errors. That has forced us to make more robust code that could handle unexpected errors and retry the query after a reasonable delay. Writing robust code is always a good idea but proper error handling is often skipped to save time, unexpected errors would occur at some point regardless, so we may as well code for that and handle them elegantly.
There are definitely some enhancements we’d like to see with the GraphQL API, but it’s meeting our needs currently and we’re excited to see where ShipHero developers take it.
Hi @csraspini
So as for Magento 1 we don’t support it, but I believe even Magento is not going to support it anymore. We do have a Magento 2 integration, but not really related to our GraphQL API
Please let me know if this doesn’t answer your question or if I can help you with any other doubt about this.
Thanks again!,
Tom
Yes, we are aware of this and are in the process of upgrading to Magento 2. But as any developer would know, changing system entirely is not a short process. It will take the better part of a year to complete our upgrade. For this reason, we are very wary about having to create an entirely new integration to Magento 1 just to have to start all over again when we have upgraded to Magento 2. I am certain that we are not the only ones in this situation, any Magento developer will tell you that the upgrade to Magento 2 is a very big deal.
With that in mind, I appreciate the new info (deprecation 7/31, removal 9/1) and would like to ask: any chance the removal date may be extended, to assist those customers–such as me, the others who have expressed their concern on this forum, and I’m certain several others–who will be in great difficulty going from GraphQL to REST?
