Hacker News Reader

Comment by deniska | Hacker News Reader

I'm building integrations with various marketplaces at a company I work at (fulfilled by seller kind of deal), and I can confirm, it's much easier for us to schedule an HTTP request once in 15 minutes than to create a custom HTTP service responding to specific requests from 3rd parties.

We're in the business of selling things, we're not in the business of building HTTP services. Our ERP-like thing is down for maintenance from 10pm to 11pm, so we can't use it as a platform for responding to webhooks.

I'll hack something together in a pinch when it's the only way to get orders from a marketplace service, but then eventually I'll have to explain to my colleagues how to linux, how to HTTPS, how to python, how to WSGI, and all other stuff our company typically doesn't do, but has to do now, because this particular marketplace wants to POST orders to us.

View on HN

You might want to check out https://hookdeck.com (I work on it). We built it precisely for this use case, you shouldn’t have to spend of bunch of time building webhook ingestion infrastructure.

Any way to use cname for hookdeck? Curious if we can have webhooks route to example.com instead of hookdeck.com

Also, any SLA on uptime?

Just curious, how would you prefer to receive these notifications?

By polling an endpoint provided by the marketplace with parameters "since" and "to" to filter events by the time they happened. We typically set "since" to two days ago and "to" to tomorrow. We're not in the hurry, we have an hour or two of leeway between receiving a message and having to act on it. I certainly prefer the polling solution for that usecase. Easier to set up, easier to debug, easier to notice that something is wrong.

Maybe there's an opportunity here for some kind of buffering service that would receive webhooks and present them as a stream of events. Or maybe something like this already exists?

I was thinking the same thing, it's kind of why I asked the question. :)

On the one hand, it seems like something too simple to expect people to pay for.

On the other, it's so simple it wouldn't be a huge loss to try it out and see if they will.

That's more or less what I implemented with a bit of python and sqlite. It works, but it's another piece of infrastructure to care about in a shop full of people who never had to care about that kind of infrastructure. For example we (well, I, really) forgot to configure certbot to restart nginx after renewing a cert, and only noticed that after a marketplace notified us that they're temporarily pulling off our SKUs due to our HTTP service being misconfigured.

Can this be a 3rd party service? It certainly can be, but it's hard to make a generic one for any kind of webhook. Some marketplaces expect a dynamic response, like replying the order number we assigned internally (I typically just echo back the number they gave us with some prefix, but it's still more smarts than just replying with empty 200 OK).

And I've seen services which aggregate popular local marketplaces into API which is easier to work with, but they require to concede some other parts of the business we'd rather keep in-house, like assortment and inventory management.

Reply on news.ycombinator.com