The API-as-a-Marketplace
versionone.vc
versionone.vc
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.
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.
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.
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.
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.
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.
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)
-------------------------------------------
>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.
>>”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?
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.
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.
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).
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.
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.
I see examples for medical data in this thread, which is notoriously slow to "open," so I'm curious what the reasoning may be...
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?
Marketplaces only work if they deliver customers, and I’ve simply seen almost no volume of customers searching within these systems.
Say goodbye to vendor API lock-in!
=> 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)
=> select count(1) from hostio.rank where split_part(domain, '.', 2) = 'vc' and rank < 10000000;
count
-------
406