Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The API-as-a-Marketplace

versionone.vc

Post reply on HN
Print view View original

31–40 of 42 posts

Re: The API-as-a-Marketplace

#31

Post by RileyJames »

greatNespresso wrote: post #29
rhenzabel wrote: post #16

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.

Re: The API-as-a-Marketplace

#32

Post by RileyJames »

orasis wrote: post #30

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?

Re: The API-as-a-Marketplace

#33

Post by rhenzabel »

greatNespresso wrote: post #29
rhenzabel wrote: post #16

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?

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.

Re: The API-as-a-Marketplace

#34

Post by maest »

BiteCode_dev wrote: post #7

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!

Re: The API-as-a-Marketplace

#35

Post by siphor »

bwertz wrote: post #25
alberth wrote: post #21

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…

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.

Re: The API-as-a-Marketplace

#36

Post by 1270018000 »

drchopchop wrote: post #19
lurcio wrote: post #13

Earlier quoted context omitted.

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.

Re: The API-as-a-Marketplace

#37

Post by derefr »

siphor wrote: post #35
bwertz wrote: post #25

Earlier quoted context omitted.

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.

Re: The API-as-a-Marketplace

#38

Post by akingyens »

siphor wrote: post #35
bwertz wrote: post #25

Earlier quoted context omitted.

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.

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

Re: The API-as-a-Marketplace

#40

Post by haltingproblem »

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.

Post reply on HN