open-api
open-api copied to clipboard
etsy
[FEATURE] New real time feeds/suscriptions
Not sure if this is really part of the OpenAPI, but it is a request anyway, hope that is ok!
Is your feature request related to a problem? Please describe. The existing API provides real time feeds and PuSH subscriptions for listings. Unfortunately, there is no feed, subscription, or webhook available for orders received.
Describe the solution you'd like A way to register for notifications when a new order is received to my shop so I can update inventory on my own external inventory software automatically. I'm sure there are other events that might be interesting for other developers too.
Describe alternatives you've considered Could poll the regular orders endpoint, but that is slow, inefficient, and more prone to errors/missed orders.
I am 100% behind you on having a webhook for orders received. I have floated the idea with the development team several times as in one of our applications having this simple webhook would reduce our API calls by over 70% - resulting in a more efficient application and much reduced load on Etsy servers. Every other selling platform I integrate with has this, and I find it strange that Etsy doesn't. As a result, we resort to polling for new orders all the time. In v2, this is further frustrated by having to call at least 3 different endpoints to achieve the full order information required.
If there was ever a feature suggestion that should be taken on board and implemented, it should be the availability of said webhook.
Hi @foxfriends and everyone else +1-ing this feature! We're really happy to be hearing from you and completely see the need for webhooks.
We're investigating how we can best support this but investigations are still preliminary. We'll keep you posted on how things proceed!
This would be the best possible improvement by far that Etsy could add to their new API. It's actually beneficial for Etsy too so we don't have to hit those server every minute checking for new sales.
+1 This would be a game changer for my company. We are looking at adding Etsy as a marketplace for our clients to choose from but would need real time order notifications.
I saw someone did that, may not notify the App instantly. Does anyone have an idea how do they do it?
https://automate.io/integration/etsy/webhooks
Unless they have a deal with Etsy to have a custom webhook solely for them, it's likely that they are just polling your shop on a regular basis, detecting a new order then via Automates "webhook" they inform you. So from your perspective, you subscribe to Automates webhook and have that webhook feeling, but it's not a true webhook been Automate and Etsy.
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: JoeHo @.> Sent: Thursday, August 19, 2021 3:02:25 PM To: etsy/open-api @.> Cc: Subscribed @.***> Subject: Re: [etsy/open-api] [FEATURE] New real time feeds/suscriptions (#28)
I saw someone did that, may not notify the App instantly. Does anyone have an idea how do they do it?
https://automate.io/integration/etsy/webhookshttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautomate.io%2Fintegration%2Fetsy%2Fwebhooks&data=04%7C01%7C%7C63c15d6f181f41fb44ca08d96319f955%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637649785478149576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0gDMFfY2dovUEWfUIUFoIw%2B6plhvOjb8KuiZZByZslo%3D&reserved=0
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fetsy%2Fopen-api%2Fissues%2F28%23issuecomment-901941967&data=04%7C01%7C%7C63c15d6f181f41fb44ca08d96319f955%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637649785478149576%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SOtH8srvIRTmRh9cb5kjsR%2BSy6LSdUncj9KoRvGPCp8%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFKGDFYFRLFLIVBUKNFKQUTT5UFHDANCNFSM4XOELDZA&data=04%7C01%7C%7C63c15d6f181f41fb44ca08d96319f955%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637649785478159532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MsXOWc%2BvaQ%2Bl1DNv3F%2B%2BsTssA%2BLmu6HLY75i8i1lP0U%3D&reserved=0.
Hi @foxfriends and everyone else +1-ing this feature! We're really happy to be hearing from you and completely see the need for webhooks.
We're investigating how we can best support this but investigations are still preliminary. We'll keep you posted on how things proceed!
Are there any updates?
Frankly, it feels weird that new and shiny API won't have the realtime feeds or any alternative. This makes a lot of integrations difficult and calls for nasty hacks.
Yes real time feed would be extremely useful. I would like to suggest supporting google pubsub, shopify does.
Thanks James
+13 for webhooks for other stuff too tho like when a seller posts new items or recieves a new review such that new items and reviews can be sent to mailing list or displayed on various other platforms
I'd like to propose an alternative to webhooks that gets the job done just as well (or better), and may be simpler to implement on your (Etsy's) side:
/events
A list of the last 30 (or however many) days worth of events for the calling application (not shop). Essentially the same data that would have been posted as webhooks, but polled from our end. Stripe does this (they do webhooks too, but you don't really need both):
https://stripe.com/docs/api/events
Someone laid out some of the reasons to do /events instead of webhooks here: https://blog.sequin.io/events-not-webhooks
But in my own words, here's why I think /events is better than webhooks:
- /events is easier and simpler to implement for Etsy (which means it's more likely to be done sooner). You don't need a job queueing system, you don't need new UX or API for applications to submit the webhook targets. All you need is a table of events with an index on appid and date.
- /events is extremely cacheable. You can cache the results at http level if you include the auth header in the cache key. There should be minimal load, even if apps are polling once a minute.
- /events is more robust. With webhooks, Etsy has to keep retrying on a schedule and give up eventually. Stripe gives up after 3 days. With /events, there's no execution cost, just storage cost, so you can retain data for much longer.
- /events gives better feedback to the client. If our polling fails, we get an error. If a webhook fails (say, something misconfigured on our end) then we don't know about it unless there's some sort of "email the app admin" process set up on Etsy's end. More complexity.
- With webhooks, we really need to poll anyway. Webhooks fail, our apps have bugs, etc. If the webhook retry period is 3 days, it's possible to miss a hook. The only way to be 100% sure we haven't missed a webhook is by polling. And right now that's a PITA - polling each merchant's data separately. We need the /events endpoint anyway. And if we have /events, we don't really need webhooks!
- The main argument for webhooks is "faster notification" - but polling /events once a minute should be plenty fast enough. Etsy can decide how much "real load" this turns into by picking the cache period.
I'd like to propose an alternative to webhooks that gets the job done just as well (or better), and may be simpler to implement on your (Etsy's) side:
/events
So the developers will still need to poll and waste their and Etsy's resources to find out if there are any changes? Imagine making an app that needs to pick up new orders from Etsy, and you have thousands of users. Now do the maths and see how many requests would that be if you want to at least maintain a minute of latency.
- I'm sure the smart folks at Etsy can figure out how to use CloudFlare or similar cache to dial the polling load to a trickle.
- A smart implementation of /events would be application-specific, not store-specific. Scaling is linear with the number of apps.
- As an app developer, you still need to poll for safety. Webhooks can and do fail.
- It's strictly better than the current polling approach.
The /events approach, managed intelligently, is less load and less work for both Etsy and app developers.
It is not only about wasting resources on Etsy's side. It is a huge waste on the app's side to check for changes every minute for thousands of users. Combination of webhooks and events is fine, as Stripe does, but I'm not sure why are you recommending a crippled solution which would bring very little benefit to the developers...
Making one call a minute (or one every few minutes, or however long Etsy decides is reasonable - they ultimately decide how often we poll via the response cache header) is not a "huge waste of resources" unless you're running on a TRS-80.
Right now Etsy requires an enormous amount of polling that actually is a huge waste of resources. An /events endpoint would be dramatically better without requiring a major investment. On the other hand, building webhooks infrastructure requires a large durable job queueing system, a monitoring system, a configuration DX, and a way of notifying app developers on failures. And careful developers will still have to poll anyway (because even big companies like Paypal screw up webhooks occasionally, and the consequence is lost transactions).
I'm guessing you've never worked inside large companies. Adding a new endpoint to your existing system is much easier than setting up and maintaining a massive new piece of infrastructure.
It's not one call a minute, it's one call times how many shops you have to keep in sync, unless you can somehow tell the API which shops you are interested in a single call. Anyway, there is no point in arguing as it doesn't do good to anyone, Etsy should ultimately decide which solution will they implement.
Please reread my posts more carefully. The whole point is to avoid polling for each shop:
A list of the last 30 (or however many) days worth of events for the calling application (not shop).
Thats for the discourse everyone! While we have not made any firm decision on this either way we have been talking about webhooks recently and how we might be able to implement this. @stickfigure your /events suggestion is a good one as well and we'll discuss that as well. Perhaps doing both may be in order. I'm not really sure. But rest assured that discussions have begun.
+1, without this receipts / orders must be polled for which increases the request count once the number of stores rises, we recently exceeded our daily request limit and had to reduce the polling frequency.
