<story><title>Show HN: M3O – Universal Public API Interface</title><url>https://m3o.com</url><text>Hey all, I&amp;#x27;m Asim, the founder of M3O, a curated catalog of APIs that provides simple abstractions for the most common API use cases. The idea is to create a single place to explore, discover and consume public APIs as higher level building blocks.&lt;p&gt;Most of the time I don’t use all the features of an API and I assume most devs don&amp;#x27;t either, so picking and choosing the common patterns, abstracting it away and surfacing a new building block is useful. For example, Twilio has a lot of APIs but I only care about SMS. Even then I just want a quick way to send it. So stripping it all away results in something that&amp;#x27;s one endpoint and 3 fields (from, to and message).&lt;p&gt;Another example is something like email. There are services like sendgrid that provide a really feature rich experience for email but I’m just looking for something simple that will let me send plain text or html.&lt;p&gt;There are a number of API marketplaces out there, but we’re doing something different—our goal is to improve productivity. For example, RapidAPI has thousands of APIs, but there’s a lot of duplication. It’s overwhelming for developers. Choice is the enemy of productivity. AWS, on the other hand, offers a curated catalog of services where each focuses on a specific problem. We feel the same: from an API perspective you only need one of each building block. You only need one SMS, Email or Geocoding service.&lt;p&gt;I&amp;#x27;ve been obsessed with this problem since working as an SRE at Google in 2011, seeing how the internal platform and APIs were being used by teams. I then worked at a ride hailing startup called Hailo where we got to build something similar, and experience the velocity of development in shipping products on top of simple, easily discovered APIs. I spent the next few years bootstrapping an open source project called Micro, trying to get people to standardize their API development to reach this goal.&lt;p&gt;Ultimately it took raising funding to take a real shot at it. After seeing the productivity Google unlocked and what Hailo could have done with their platform, it was clear to me it could and should be a product: a single way to consume APIs with one platform, one account and one framework.&lt;p&gt;Our goal is to build an API catalog that can act as the building blocks for most use cases, and then double down on services that have a lot of demand so we can improve the features and reliability.&lt;p&gt;In the wild, every API looks different, the docs are different, you have to figure out if there&amp;#x27;s client libraries or not. We unify all that, so everything looks and feels the same. All our docs are generated based on OpenAPI specs, and we code generate examples&amp;#x2F;client libraries for JS, Go, Dart and the CLI. It means you only ever need one client to access all these APIs.&lt;p&gt;Unifying API development and consumption requires a lot of resources to do at scale, hence it&amp;#x27;s only happening inside fast growing startups and large tech cos. There are a lot of barriers to entry. Getting started isn&amp;#x27;t easy. Our approach has been to first nail API development for ourselves and then focus on API consumption by end users— ultimately we want to let anyone offer APIs on our platform. That requires enough large scale distribution and inbound traffic to make an attractive proposition to developers.&lt;p&gt;We&amp;#x27;ve spent a year building the product with a lot of feedback on what worked and what didn&amp;#x27;t. We’ve signed up 8000 people, served 5M API requests and have 60+ APIs on the platform.&lt;p&gt;On billing: we&amp;#x27;re still figuring it out and would like feedback. It started as a free product, then moved into per request pricing. Unfortunately that&amp;#x27;s hard to scale without a lot of volume and it felt like people were more used to subscriptions for SaaS products so that&amp;#x27;s the route we&amp;#x27;ve gone.&lt;p&gt;Anyway that&amp;#x27;s us, hope you try it out (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;m3o.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;m3o.com&lt;/a&gt;), and would love to hear your thoughts in the comments!</text></story><parent_chain></parent_chain><comment><author>fadesibert</author><text>Some questions come to mind after poking around the catalogue (having worked in an enterprise that ended up with many API catalogues, and now many APIs in startup land, I get the pain point).&lt;p&gt;- What&amp;#x27;s the difference between currency and forex? They look to be serving the same case, but in different ways, without reference to one another - challenging the implied claim to &amp;quot;this is the best way to X&amp;quot;&lt;p&gt;- payments. Stripe&amp;#x2F;... integration into any moderately saas business is a ball-ache. Current &amp;quot;subscription management&amp;quot; services are woefully, laughably inadequate . If you had a &amp;#x2F;pay endpoint, where I could offload payments, I would have been quite happy indeed
- email. Needs better documentation. When sending an email through this interface, is there impersonation? Or is it &amp;quot;me@mine.com &amp;lt;someemailservice@someintermediary.foo.bar&amp;gt;&amp;quot;&lt;p&gt;Neat idea - the enterprise survivor in me wishes you success</text></comment>
<story><title>Show HN: M3O – Universal Public API Interface</title><url>https://m3o.com</url><text>Hey all, I&amp;#x27;m Asim, the founder of M3O, a curated catalog of APIs that provides simple abstractions for the most common API use cases. The idea is to create a single place to explore, discover and consume public APIs as higher level building blocks.&lt;p&gt;Most of the time I don’t use all the features of an API and I assume most devs don&amp;#x27;t either, so picking and choosing the common patterns, abstracting it away and surfacing a new building block is useful. For example, Twilio has a lot of APIs but I only care about SMS. Even then I just want a quick way to send it. So stripping it all away results in something that&amp;#x27;s one endpoint and 3 fields (from, to and message).&lt;p&gt;Another example is something like email. There are services like sendgrid that provide a really feature rich experience for email but I’m just looking for something simple that will let me send plain text or html.&lt;p&gt;There are a number of API marketplaces out there, but we’re doing something different—our goal is to improve productivity. For example, RapidAPI has thousands of APIs, but there’s a lot of duplication. It’s overwhelming for developers. Choice is the enemy of productivity. AWS, on the other hand, offers a curated catalog of services where each focuses on a specific problem. We feel the same: from an API perspective you only need one of each building block. You only need one SMS, Email or Geocoding service.&lt;p&gt;I&amp;#x27;ve been obsessed with this problem since working as an SRE at Google in 2011, seeing how the internal platform and APIs were being used by teams. I then worked at a ride hailing startup called Hailo where we got to build something similar, and experience the velocity of development in shipping products on top of simple, easily discovered APIs. I spent the next few years bootstrapping an open source project called Micro, trying to get people to standardize their API development to reach this goal.&lt;p&gt;Ultimately it took raising funding to take a real shot at it. After seeing the productivity Google unlocked and what Hailo could have done with their platform, it was clear to me it could and should be a product: a single way to consume APIs with one platform, one account and one framework.&lt;p&gt;Our goal is to build an API catalog that can act as the building blocks for most use cases, and then double down on services that have a lot of demand so we can improve the features and reliability.&lt;p&gt;In the wild, every API looks different, the docs are different, you have to figure out if there&amp;#x27;s client libraries or not. We unify all that, so everything looks and feels the same. All our docs are generated based on OpenAPI specs, and we code generate examples&amp;#x2F;client libraries for JS, Go, Dart and the CLI. It means you only ever need one client to access all these APIs.&lt;p&gt;Unifying API development and consumption requires a lot of resources to do at scale, hence it&amp;#x27;s only happening inside fast growing startups and large tech cos. There are a lot of barriers to entry. Getting started isn&amp;#x27;t easy. Our approach has been to first nail API development for ourselves and then focus on API consumption by end users— ultimately we want to let anyone offer APIs on our platform. That requires enough large scale distribution and inbound traffic to make an attractive proposition to developers.&lt;p&gt;We&amp;#x27;ve spent a year building the product with a lot of feedback on what worked and what didn&amp;#x27;t. We’ve signed up 8000 people, served 5M API requests and have 60+ APIs on the platform.&lt;p&gt;On billing: we&amp;#x27;re still figuring it out and would like feedback. It started as a free product, then moved into per request pricing. Unfortunately that&amp;#x27;s hard to scale without a lot of volume and it felt like people were more used to subscriptions for SaaS products so that&amp;#x27;s the route we&amp;#x27;ve gone.&lt;p&gt;Anyway that&amp;#x27;s us, hope you try it out (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;m3o.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;m3o.com&lt;/a&gt;), and would love to hear your thoughts in the comments!</text></story><parent_chain></parent_chain><comment><author>lonelyprograMer</author><text># 
I&amp;#x27;m so frustrated, this product was advertised so many times and it also was &amp;quot;rebrended&amp;quot; a lot. At first it was an API hub, then it became an alternative to AWS, then the author was selling it as serverless thing, now it is Universal Public API Interface.&lt;p&gt;Author is also know for working on project called micro that changed the license once so you could not use it for any purpose that competes with the project, but it was changed to Apache later again. Such bold decisions of the author and now the creator of m3o service makes one to think twice before trying the product.
Link to the commit: [Update LICENSE · micro&amp;#x2F;micro@31c1254 · GitHub](&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;micro&amp;#x2F;micro&amp;#x2F;commit&amp;#x2F;31c12547b9cd4a4fd0176be5997b09650a3985ea&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;micro&amp;#x2F;micro&amp;#x2F;commit&amp;#x2F;31c12547b9cd4a4fd0176b...&lt;/a&gt;)&lt;p&gt;Besides all of that product is bad, therefore doesn&amp;#x27;t suite for production use cases. A few points:&lt;p&gt;1. Pricing is dumb. &amp;quot;Unlimited API requests&amp;quot;, &amp;quot;1M requests per credit&amp;quot;, what does it mean?&lt;p&gt;2. Community support? Where is the community and the community can answer my questions if you don&amp;#x27;t have any documentation?&lt;p&gt;3. Any SLA? No even for Business plan?&lt;p&gt;4. Authentication and user management. Are you crazy? Who is going to use it? No idea is the data encrypted or not, can I backup it? Do you have failover solution? Again, SLA? This kind of API can&amp;#x27;t be just used by anyone in any production environment.&lt;p&gt;5. SMS API relies on credits. Where is the pricing for credits on your website?&lt;p&gt;6. What about OpenAPI, JSON Schema or GraphQL? JS, Go, Dart and Bash SDKs are not enough. You probably don&amp;#x27;t have enough resource to cover 99% of the most used programming languages, so just publish OpenAPI spec and let the customers to generate code in Java, for instance, until you finish the SDK for Java.&lt;p&gt;*Conclusion*
It seems that m3o is just a pile of different API that are supposed to be an alternative to SMS provides like Twillio, some finance APIs, Email providers like Sendgrid, a few products from AWS etc. Yet it doesn&amp;#x27;t even cover a 1% of the features that those companies do provide.&lt;p&gt;Please, be responsible for your product, don&amp;#x27;t mislead your customers. If you want people rely on your product in production put in alpha or beta stage, make it free or let a limited number of users test it, work on every API you want to provide thoroughly, write documentation AND then put sell it.</text></comment>