Discussing APIs and development related to customers, discounts, and order management.
Hi,
this has been asked a few times, but I'd like to point out that the integration of refunds, line items etc. on an order level (or similarly, adding variants to the product endpoint) is enormously useful for analytics users. If Shopify could add a transactions array like they already have for other objects, that would be extremely useful. Is that something that could happen anytime soon?
I understand that one could also get this data using the GraphQL API, however mixing APIs or completely changing APIs from our end is a less than ideal workaround as well.
Best,
Bijan
Hey @Bijan,
In case you aren't already aware, this is available in REST through the transactions endpoint, though it does require an extra call to /orders/{{##order_id##}}/transactions.json
. I'll send up your feedback, but to be honest I'll be surprised if this is implemented. The order API response can already be quite large, and this functionality is available in GraphQL as you mentioned.
Definitely understand that switching APIs is no small undertaking, however I'd consider that the effort required up-front will be far outweighed by future benefits. Especially for an analytics app, GraphQL will allow you to make connections on almost every resource, and should allow you to get the information you need with significantly fewer calls.
JB | Solutions Engineer @ Shopify
- Was your question answered? Mark it as an Accepted Solution
- To learn more visit Shopify.dev or the Shopify Web Design and Development Blog
Thank you for your reply. I was well aware of the option to make individual order calls, but that's a pretty bad practice for data warehousing usecases.
You see, the issue is general batch loading of transactions data. The way I see it, one of two alternatives would suffice:
1) add it to the orders endpoint like you have with pretty much all other resources, as described earlier
2) have an endpoint that can paginate through all transactions irrespective of order, with an updated_at filter
Either would work. I have no preference. The use case is a job that runs every hour or so and simply gets the latest data for that hour, and nothing else. Your API documentation is misleading insofar as it is possible for almost all objects, and it is extraordinarily frustrating to then realize that it is, in fact, not possible for all objects after already completing 90% of the work. It seems like you had use cases like mine in mind and then just abandoned it on the last mile.
Making extra API calls for each order is simply not a good practice and does not allow for good standardization. This is completely reasonable for app development when it is expected that a user interacts with a single order at a time, but not for the updating of data warehouses and the like.
Thus, I strongly suggest that you add one of the two abovementioned options.
Best,
Bijan
I have now investigated the GraphQL API for this usecase and suffice to say, I am not a fan. That is not to say that GraphQL doesn't have great use cases. I can see how it can be very useful. However, using it for loading data into a data warehouse is certainly not one of them. Just trying to get some basic information leads to exceeding query cost limits. Running pagination way down for shops, on the other hand, makes it exceedingly slow.
Further, there is no GraphQL object for transactions either - I can only get it via the orders. So now I have the choice between:
- get orders via GraphQL, which I can't, because I can't really get all the information I need in one API call, or
- get orders via GraphQL, which I can't, because I can't get transactions data without additional API calls on a per-order basis
I can see that a lot of custom logic and numerous API calls would work, but that's breaking my project goal. One of my previous suggestions would really be helpful here.
Best,
Bijan