Hacker News new | past | comments | ask | show | jobs | submit login
The API-as-a-Marketplace (versionone.vc)
97 points by imartin2k 71 days ago | hide | past | favorite | 41 comments

We've been working on something in this space called Violet: https://violet.io. At the core we're a headless API that connects merchants looking to sell their products natively in new channels with the developers (https://violet.dev) who are building those channels.

I am really sorry, but looking at your website, I did not understand what's the purpose of your company. Reading up your comment, it does not make much more sense to me. Are you somehow like snipcart?

From reading through their site it seems to replace affiliate links with api calls.

Ie: I have a website (Channel), rather than place affiliate links, I can request products from an api and sell them directly to my users (audience).

Makes more sense when the channel is not a website (ie something that doesn’t have links) like a instagram story, or virtual environment. You want to sell the latest console / game from Microsoft, they provide an api, you pull the trailer, screenshot (media) and a price. The user can click buy there and then, you take payment via stripe and send an order to Microsoft via the api. Microsoft then fulfils the order.

Somewhere between affiliate and retailer.

What @RileyJames said is spot on. When you think about it outside of the lens of websites, it starts to become more clear. Our thesis is that apps should be able to sell natively, without any form of clickouts to external websites, which is how traditional affiliate links operate today. We believe that transactions should be able to occur natively in any environment that has an internet connection. If commerce is ever to occur in environments like games, voice, VR, etc; clickouts would likely be impractical, and a headless API would be needed to facilitate the transaction. This headless API is what we've been working on.

We essentially integrate with all of the ecom platforms (think BigCommerce, Magento, Shopify, etc) and normalize their catalog and checkout/order API's into this single headless API. Developers can then integrate with this single API, and gain access to the products in our system, which are sourced from merchants on all of those platforms. Developers can then add native checkout (no clickout) to their apps, and earn a commission (defined by the merchant) for each order they facilitate. These orders are written back directly into the merchants existing tools, where the order appears as if it had been placed on their website.

Also, I do agree that our landing page can be pretty confusing. We're serving a double-sided marketplace and are still working on finding that right language that makes sense to both sides.

Reminds me of energy brokerages, which are a thing in some US states. Rough idea is energy-consumers will ask for energy from an intermediary (the brokerage), which will purchase electricity in the form of a contract from a pool of suppliers for the best available price.

I'm building one called Openship. Here's more about it: https://www.openship.org/blog/2019-10-23-using-open-source-t...

Curious: how is Openship different from building your store with apps from the Shopify Apps store?

I used to manage my shops using Zapier and Google Sheets for many years. Our products were coming from many different sources and many things would fall through the cracks. Customer service would be slow since agents would have to know where orders need to be returned and the return process.

Openship started as an internal project so all this could be managed from one dashboard so we could scale to 5000+ SKUs without the system being overwhelmed. Orders can be routed to any channel that has APIs to search products and create carts.

The other benefit of Openship is that your operations are abstracted out of Shopify. If you ever want to leave Shopify or roll your own e-commerce backend, Openship and your operations won't skip a beat. Let me know if you have any other questions.

My girlfriend is (one of the many people) building a Blockchain-API-as-a-marketplace for commodities trading: https://www.vakt.com

It's amazing how many billions of dollars are still transacted via phone and paper records by organisations who ultimately have to rely on good faith to get oil from A to B (in possession of C and owned by Z). I can't imagine what it would take to verify a chain of actions taken a couple of years ago with the systems in place. Impossible.

I imagine other commodities are the same. I would never have guessed there's still so much efficiency to be gained in these huge, old-as-dirt markets. Technology, huh.

All well and good but blockchain doesn’t invalidate the need for ‘good faith’, which is actually due diligence supported by rule of law.

Right, which is why "enterprise blockchain" generally means a bunch of people fumbling around with Ethereum/Solidity, failing to build anything more secure than a read-only SQL database, and inheriting all the bad characteristics of Bitcoin

Is there a word for "Creating a solution for a problem that doesn't exist?" The descriptive linguist in me thinks we can start calling that a blockchain.

Yup, blockchain still has yet to address the rules of society and the expectation to be able to force financial transactions by court order

I'm not sold on the ledger-as-single-source-of-truth notion either. Blockchain is a solid technological choice for critical transactions that need to stand up to independent verification, but it's certainly not the only one. If it makes enough of a difference to turn these markets digital faster, I'm happy.

What I like is this notion that there are still huge, opaque markets that are extremely costly to take part in. And that tech can whittle them down to be very fast, cheap and easy to participate in.

We pay inefficiency and arbitrage taxes on everything we produce and consume. How many cents out of a dollar I spend on bread go to someone whose only value in the process is manning a phone or providing working capital? The sooner those two go away, the better.

> We pay inefficiency and arbitrage taxes on everything we produce and consume. How many cents out of a dollar I spend on bread go to someone whose only value in the process is manning a phone or providing working capital? The sooner those two go away, the better.

Those inefficiency and arbitrage taxes will then be replaced with social security / ubi taxes, as fewer people are needed in the workforce.

Which is probably a good thing, but don't think that you're going to see any substantial savings in the cost of your goods. If it doesn't go in taxation (because it's a unique thing to a few companies), it'll just be additional profit capture for those at the top.

I’m very ok with that idea, personally. Let’s unemploy as many people as possible and pay them to be happy instead.

I'm not so sure money can buy happiness.

There is an amount of life fulfillment that comes from working, and many would likely start having mental health issues (as we are seeing with the Covid lockdowns)

Several people I’ve spoken to are in lockdown and still working 10 hour days. They’re definitely less happy than the ones that are receiving up to 80% pay to not work. Their work does not fill their lives with meaning or purpose, and instead prevents them from being able to actually spend their days as they please, as they remain confined to the 8am-6pm work schedule.

Chain of custody forms have existed for centuries.

What does this mean? I have read this many times and it must be slow brain day. I seriously want to try and understand.


>What is an API-as-a-marketplace?

>Just like a traditional marketplace, an API-as-a-marketplace has two sides: suppliers and buyers. But, the interface is different.

>In a traditional marketplace, discovery and purchase are done on the application layer. The transaction process is visible to the end user and is essentially a part of the platform’s identity and brand.

>In an API-as-a-marketplace, the API is the UX for the transaction; that is, the transaction occurs on the infrastructure layer and is abstracted away from the end user.

I was tracking with the article until this except.

>>”But unlike Stripe, Twilio, and Postmates, the supply of an API-as-a-marketplace is not necessarily a commodity. That is, should they choose to, developers and businesses (or even their end users) can pick their suppliers based on whatever requirements they have. ”

I’m confused. Isn’t the definition of being able to swap out one vendor for another and receive the same service back in return ... the exact definition of a “commodity”?

And is he suggesting that these other API company’s (stripe, twilio,postmates) are NOTa commodify?

I think you're saying the same thing.

Stripe, Twillio, etc. provide access to commodities.

The "API as a marketplace" concept postulates that there are situations in which the supply is differentiated and you care about with which supplier you get connected.

Isn’t postmates, or like uber eats an example of that though... you care where you’re getting your food.

Unlike restaurant delivery, grocery delivery services are right now operating mostly on non-exclusive contracts with the upstream chains (because the chains are big and have a lot of negotiating power; and because the chains have a real need to partner with different delivery services in different markets, because no delivery service exists everywhere the chains are yet.) There's no real market for delivery from mom-n-pop produce markets, and so there's nobody for grocery delivery services to bully into accepting an exclusive contract with them.

If you can get the same groceries from the same store no matter which portal you order through, then the portal itself is a commodity.

On the Postmates App, yes, you definitely care about where you're getting your food. The marketplace here is between eater (buyer) and restaurant (supplier).

However, if you are a business that wants to offer delivery directly and don't want to create your own delivery network, you would use Postmates API. In this case, the business (buyer) doesn't care about each individual supplier (i.e. the fleet is a commodity).

I wish OP would dive a bit more into the Stripe example as not-a-marketplace.

There's Spreedly, which at first glance might be more of a marketplace.

But then there's also an argument that Stripe itself is an API-as-a-marketplace, where they support different card providers/types, ACH, and a host of global methods.

Is one interpretation more correct than the other? (at least as it relates to an investment thesis)


Another example is the Priceline API (and the GDS's before them), which I believe solidly qualify as an API-as-a-Marketplace under this definition.

> Just like a traditional marketplace, an API-as-a-marketplace has two sides: suppliers and buyers.

When I make a payment on a site with stripe (my transaction-in-need-of-payment-processing being the "demand" side), there's not really a pool of "supply side" vendors I'm trying to be matched with... I'm just interested in knowing that my money is going to the business I'm checking out with.

To concoct this into an example that's more of a marketplace:

- the business owner needs a payment processor for people checking out like me -- payment processing is the service

- imagine that transaction fees varied based on the nature of the individual transaction (imagine say an individual <$1 visa transaction is different from a $<1 mc transaction is different from a $1-$10 preferred-vendor visa transaction or something hypothetical like that)

- there's multiple payment processors that offer various fees -- Stripe, Braintree, Paypal, etc.

The marketplace solution now is the one that matches the demand side (a $1-$10 preferred-vendor visa transaction) to the payment processor that makes most sense (supply side) for each individual transaction.

Obviously payment processing works different than this. That's why Stripe is an API, not an API-as-a-marketplace.

Now, replace "payment processing" with "shipping" and "$1-$10 visa transaction" with "1-10lb package going to Somewheretown"... now you have a situation that sounds like the real world. That's the niche the article says Shippo is filling.

What I'm curious is why there's not yet a marketplace for consumer-generated data. Thinking things like wearables. Is it that these wearables are too miserly over their data, or are there other considerations that make this more difficult than some of the more common ones I've seen such as e-commerce and supply chain.

I see examples for medical data in this thread, which is notoriously slow to "open," so I'm curious what the reasoning may be...

Humanapi (https://www.humanapi.co/) is building something in this regard

I would argue that ad auctions on Google and Facebook are a form of marketplaces for consumer-generated data.

Surely privacy is a huge concern, especially for something like wearables.

I think I may be missing the point of what the article is getting at with API-as-a-marketplace versus traditional API marketplaces.

I think even after reading the article and looking at some of the examples, I'm confused at what's being talked about here, and some of the additional concerns that would arise with something like wearbles.

It seems like API-as-a-marketplace are providing services where an Instagram-like company could add the "Instagram shops" section right into their application as opposed to have to make a separate shop and checkout process?

Having run some products through these types of marketplaces I am not optimistic.

Marketplaces only work if they deliver customers, and I’ve simply seen almost no volume of customers searching within these systems.

These being shippo & patch? Or RapidAPI?

But what about a marketplace for APIs?

Maybe that can be implemented via an API. So I can have some code that can dynamically call this API-as-a-marketplace and decide what's the bests shipping API to use, then it would rewrite itself to use that API.

Say goodbye to vendor API lock-in!

That's essentially what RapidAPI and ProgrammableWeb do.

First time I come across .vc as TLD.

I've been seeing them more and more frequently for venture capitalist firms, in twitter bios etc. Thought I'd check our (https://host.io) ranking data for .vc domains:

    => select * from hostio.rank where split_part(domain, '.', 2) = 'vc' limit 25;
        domain    |  rank
     bc.vc        |  55389
     8x8.vc       |  66295
     bjn.vc       |  74899
     oscar.vc     |  81721
     plus2.vc     |  89589
     kissanime.vc |  96140
     compre.vc    |  97865
     nt.vc        | 106039
     animo.vc     | 107111
     yts.vc       | 115567
     mylink.vc    | 120827
     dot.vc       | 151363
     luz.vc       | 158821
     vook.vc      | 179284
     huobi.vc     | 202050
     app.vc       | 206374
     pornhub.vc   | 248283
     imi.vc       | 270076
     sf9.vc       | 276701
     btov.vc      | 281670
     175sf.vc     | 283532
     99s.vc       | 288077
     icoc.vc      | 302644
     1776.vc      | 318693
     fenbushi.vc  | 331303
    (25 rows)
Nothing particularly popular, and not many of those are VC firms! Only 406 in the top 10 million domains:

    => select count(1) from hostio.rank where split_part(domain, '.', 2) = 'vc' and rank < 10000000;
You can download the full top 10M from https://host.io/rankings if you're interested in playing with the data yourself!

Lots of version control and video conferencing companies...


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact