8 ms·

The API-as-a-Marketplace

97 points by imartin2k 6y ago

compscistd 6y ago
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.
colinclerk 6y ago
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.
- floatrock 6y ago
  > 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.
ksec 6y ago
First time I come across .vc as TLD.
- pcmaffey 6y ago
  Lots of version control and video conferencing companies...
- coderholic 6y ago
  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 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; count ------- 406 You can download the full top 10M from https://host.io/rankings https://host.io/rankings if you're interested in playing with the data yourself!
theturtletalks 6y ago
I'm building one called Openship. Here's more about it: https://www.openship.org/blog/2019-10-23-using-open-source-to-disrupt-marketplaces/ https://www.openship.org/blog/2019-10-23-using-open-source-t...
- akingyens 6y ago
  Curious: how is Openship different from building your store with apps from the Shopify Apps store?
  - theturtletalks 6y ago
    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.
rhenzabel 6y ago
We've been working on something in this space called Violet: https://violet.io 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 https://violet.dev) who are building those channels.
- greatNespresso 6y ago
  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?
  - RileyJames 6y ago
    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.
  - rhenzabel 6y ago
    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.
BiteCode_dev 6y ago
But what about a marketplace for APIs?
- rhenzabel 6y ago
  That's essentially what RapidAPI and ProgrammableWeb do.
- maest 6y ago
  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!
zemvpferreira 6y ago
My girlfriend is (one of the many people) building a Blockchain-API-as-a-marketplace for commodities trading: https://www.vakt.com 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.
- lurcio 6y ago
  All well and good but blockchain doesn’t invalidate the need for ‘good faith’, which is actually due diligence supported by rule of law.
  - verdverm 6y ago
    Yup, blockchain still has yet to address the rules of society and the expectation to be able to force financial transactions by court order
    - zemvpferreira 6y ago
      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.
      - 6y ago
carterklein13 6y ago
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...
- dajohnson89 6y ago
  Surely privacy is a huge concern, especially for something like wearables.
  - carterklein13 6y ago
    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?
- bwertz 6y ago
  Humanapi (https://www.humanapi.co/ https://www.humanapi.co/) is building something in this regard
- JacobDotVI 6y ago
  I would argue that ad auctions on Google and Facebook are a form of marketplaces for consumer-generated data.
alberth 6y ago
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?
- bwertz 6y ago
  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.
  - siphor 6y ago
    Isn’t postmates, or like uber eats an example of that though... you care where you’re getting your food.
    - derefr 6y ago
      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.
    - akingyens 6y ago
      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).
orasis 6y ago
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.
- RileyJames 6y ago
  These being shippo & patch? Or RapidAPI?
grognak420 6y ago
Chainlink
haltingproblem 6y ago
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.

97 points by imartin2k 6y ago

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.

colinclerk 6y ago

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.

floatrock 6y ago
> 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.

ksec 6y ago

First time I come across .vc as TLD.

pcmaffey 6y ago
Lots of version control and video conferencing companies...
coderholic 6y ago
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 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; count ------- 406 You can download the full top 10M from https://host.io/rankings https://host.io/rankings if you're interested in playing with the data yourself!

theturtletalks 6y ago

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

akingyens 6y ago
Curious: how is Openship different from building your store with apps from the Shopify Apps store?
- theturtletalks 6y ago
  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.

rhenzabel 6y ago

We've been working on something in this space called Violet: https://violet.io 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 https://violet.dev) who are building those channels.

greatNespresso 6y ago
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?
- RileyJames 6y ago
  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.
- rhenzabel 6y ago
  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.

BiteCode_dev 6y ago

But what about a marketplace for APIs?

rhenzabel 6y ago
That's essentially what RapidAPI and ProgrammableWeb do.
maest 6y ago
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!

zemvpferreira 6y ago

My girlfriend is (one of the many people) building a Blockchain-API-as-a-marketplace for commodities trading: https://www.vakt.com 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.

lurcio 6y ago
All well and good but blockchain doesn’t invalidate the need for ‘good faith’, which is actually due diligence supported by rule of law.
- verdverm 6y ago
  Yup, blockchain still has yet to address the rules of society and the expectation to be able to force financial transactions by court order
  - zemvpferreira 6y ago
    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.
    - 6y ago

carterklein13 6y ago

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...

dajohnson89 6y ago
Surely privacy is a huge concern, especially for something like wearables.
- carterklein13 6y ago
  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?
bwertz 6y ago
Humanapi (https://www.humanapi.co/ https://www.humanapi.co/) is building something in this regard
JacobDotVI 6y ago
I would argue that ad auctions on Google and Facebook are a form of marketplaces for consumer-generated data.

alberth 6y ago

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?

bwertz 6y ago
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.
- siphor 6y ago
  Isn’t postmates, or like uber eats an example of that though... you care where you’re getting your food.
  - derefr 6y ago
    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.
  - akingyens 6y ago
    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).

orasis 6y ago

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.

RileyJames 6y ago
These being shippo & patch? Or RapidAPI?

grognak420 6y ago

Chainlink

haltingproblem 6y ago

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.