Join For Free

We’re giving you permission now Posted 1 year ago

We just released the API Permission Add-on to easily add, manage and revoke user permissions to your private API.

Partnership is a wonderful thing. It’s the chance to create a more intimate relationship with another person, another team, another company. At Mashape, we’re all about working with others, and we’re building the tools to make API partnerships dead simple and collaborate with the team around private APIs.

Today we’re introducing our API Permissions add-on to encourage easier, stronger relationships between developers and their consumers. 

This add-on is a game-changer for API developers that want to use the billing and analytics features of Mashape without creating a public API. Just like on Github, now you can share an API just with your team. Now you can show it off only to certain prospective clients. Now you can add billing features for partners without creating custom private plans. 

We know you’re going to love this new feature as much as we do, so come check it out! You can locate permissions via the add-ons tab on your API management page.


We now accept the 1s and 0s Posted 1 year ago

The web connects us, it enables our ability to share the content that matters most. The web is not just text, it is pictures, music and video. Yet as programmers we are used to considering the response of APIs as text that can be parsed by a machine in a format we can read ourselves. We are used to JSON. But APIs are the gears that connect us to the services that underly our favorite content, to Facebook videos and Tumblr images. 

Now, Mashape enables a whole new generation of APIs with support for binary input and output.

Fortunately, APIs are just as capable of handling this data if the right structure is in place, and starting today, Mashape is here to help developers make that leap. We’ve enabled binary responses for APIs in our marketplace, further expanding the power of the marketplace.

Now, an app developer can add instagram-style filters to an image by sending its binary data through a Mashape API. Facial recognition tools can take a binary stream and return JSON, and a word cloud generator can take an essay and return an image.

Here’s an example with Ruby:

( - black and white filter on La Gioconda {Mona Lisa})

We’re incredibly excited about this update. It brings the entire community one step closer to making all APIs accessible, trustworthy, and marketable. For developers, it dramatically expands the scope of what services a Mashape-connected API can provide. It allows for greater complexity to be parsed in a manner that doesn’t overwhelm a busy coder. 

With just a click of a button you can select a JSON, JSON Array, String or Binary parameter or response. 

Just like with our JSON APIs, libraries in the five major languages of the web allow binary based tools to be platform indepedent. Binary content being used in a Rails application can be proccessed by an API coded in Java. As developers experiment with the power of APIs and the capacity of solid documentation and turnkey implmentation, we’re excited to discovery just what the next generation of APIs will enable software to do. 

At Mashape we believe in the power of collaboration. Come join us in this next step. 

Build amazing things together. 

The data says you’re going to be a psychopath. Sorry. Posted 1 year ago

23andMe introduced an API today to let the curious among us tap into their database:

"Opening our API offers an immense opportunity for customers to do more with their DNA. While 23andMe has created a number of groundbreaking and innovative tools for our customer to explore their DNA, the API will open the door to the possibility of new web-based interactive tools to be developed by external groups."
(via TechCrunch)

This is a gigantic step forward in opening up access for genetics research online. The beauty of machine learning (as discussed in a previous post) is that it’s agnostic when it comes to information sources; it’s up to humans to interpret whether the results are useful. We know from prior research that a number of diseases are strongly heritable; a person’s DNA is a near perfect predictor of a diagnosis. But while genetics alone can predict Down Syndrome, research into more complex partially inherited traits has been far less common. 

What we do know is that illnesses such as psychopathology are partially heritable, and technology can help improve the ability of science to isolate the genetics that play a major role. Throughout history, problems considered too complex have often been solved when bright people use new technology to determine the source of an underlying problem.

While it’s primitive by today’s standards, Dr. John Snow’s mapping of cholera victims in the 1850s discovered a pattern critical to eliminating the source of the illness. In this case, Snow wasn’t actually studying the disease itself; he was simply looking for a pattern. In fact, even when he discovered it, the science available was insufficient to immediately prove him correct. 

John Snow cholera map

Snow wasn’t actually studying the disease itself; he was simply looking for a pattern.

The analogy is clear, powerful, and frightening. We don’t know what kind of patterns smart people will find in our DNA. 23andMe already advertises the ability to predict blood type. We’re entering a world where a parent or potential spouse can run a genetic background check. The ethical debate surrounding that level of foreknowledge is only just beginning.


[Photo Credit: Wikipedia]

She just doesn’t get me… Posted 1 year ago

This week, two major tech events took place just miles from our office. Apple announced the iPhone 5 at the Yerba Buena Center, and Tech Crunch Disrupt SF announced its winner. Scoble had a great blog post about how, despite the upgrades to Siri in iOS 6, its context awareness was still a major flaw. 

Siri is quite stupid about context, location, and a bunch of other things.

He’s right, but context as simply more data is better data doesn’t solve the underlying problem. Siri’s bugs don’t come from a lack of data, they come from an inability to truly “get” its owner. When we use Siri, it’s with a subtle belief in the back of our head that we have our own personal assistant.

Essentially, Scoble’s issue boils down to “she has the information, she just isn’t aware of how to use it.”

Yet as anyone who’s ever worked as a personal assistant knows, just having more data doesn’t solve the problem. What still makes people better personal assistants is not access to information but an ability to predict necessary information before it is asked for. 

Scoble mentions Siri’s inability to understand the true meaning of the query, “where is my next meeting?” A bad personal assistant would easily be able to answer that question, a good one would remind you of the salient details needed for the meeting, checking Google Maps to determine the best route. 

But checking traffic patterns is something even the boss would probably remember to do on his own. A truly great personal assistant picks up on the little details. Using contextual data, a truly great digital assistant would see problems before they became problems. 

That assistant would know that his boss to get a jolt of caffeine on his way back, so he’d have a Starbucks picked out. He’d look at upcoming events and, based on traffic and the length of previous meetings, decide if the calendar needed to be changed. He’d be know if the car needed more gas, and figure that into both the route and the schedule. Finally, he’d remember that his boss liked to bring home a movie for the kids after a long day’s work, so he’d have one picked out based on a combination of what was popular at the time and what the kids enjoyed. 

A truly great personal assistant picks up on the little details. Using contextual data, a truly great digital assistant would see problems before they became problems. 

Through apps and APIs Siri can get access to all the raw data it needs to perform these functions. What Siri lacks is the ability to reason; to fill in the gaps rather than just search. Siri can understand that a “meeting” requires a check for a route, but it can’t predict if the car will need gas, even if it has the pricing data. It can find coffee shops, but it doesn’t know whether to add in a stop for coffee, despite having access to purchase information.

Siri can’t determine if future meetings should be moved because it can’t predict how long the meeting will last. Finally, it has no ability to pick the right movie because it doesn’t know anything about how previous movie choices relate to currently available options. 

TC disrupt offered a potential solution that’s near and dear to our hearts. Prior Knowledge offers a public API that can analyze existing data and “fill in” those missing rows. It discerns patterns by understanding context. The result is that if I give it data on a daily schedule and previous gas purchase history, it can determine if i’ll need to fill up on a particular trip.

 Siri can understand that a “meeting” requires a check for a route, but it can’t predict if the car will need gas, even if it has the pricing data. 

By piping in data on existing movies and previous personal choices, it can select the right movie for tonight. The examples are numerous but the point is simple: using predictive analysis, digital assistants can begin to reason. 

As an API marketplace, we’re excited whenever someone adds an API to their product. Yet what’s most awesome about Prior Knowledge is that their product is their API. These guys get that predictive analysis is information independent; as long as you can express the data in a format machines can parse, the specifics are irrelevant.

There’s no difference between picking movies and outfits (string), between being late and needing to get gas (boolean), between how long a meeting will last and how long the perfect movie is for a family evening (integer).  

Many startups lock this technology up. They work with partners to build and test their algorithms, but hold off opening up their service to the general public. These guys have taken the diametrically opposite approach. They built v1, launched at Disrupt and said “here, play with this, show us what you can do.” At Mashape, that’s what we’re all about.

We’re enthused that an API made it into the finalists at Disrupt. As developers experiment with the power of APIs and the capacity of solid documentation and turnkey implementation, we’re excited to discovery just what the next generation of API-enabled software can do. 


Mashape Launches To The Public. Now open to every Developer and API. Posted 1 year ago

Hello mashapers,

We’re super excited to tell you that we’re now officially open for every API and every developer in the world. We’re now powering more than 400 APIs and thousands of developers are relying on Mashape APIs, everyday. We can’t wait to hear your thoughts and feedback in the coming weeks.

To be part of the movement, you can simply join us on Mashape.

Hacker note: for those sad developers that were using the API (for face detection), we now have an amazing free replacment created by Lambda Labs


Mashape has added some useful features in the last year: For API providers, it now provides a ready-to-go billing system for their APIs with custom plans for private customers, the ability to charge for specific objects (SMS, MB, calls, data points, etc), auto-generated documentation and client libraries, an issues system in case the API is malfunctioning, and powerful distribution via a community of developers. For API consumers, it gives a unified place to consume multiple APIs. Mashape is the only place where you can subscribe to any API using just a single credit card, consume APIs using just the Mashape Keys and analyze the usage of all APIs consumed through its Consumer Console.

We have a lot of surprises in the pipeline and we’ll stay focused on improving the happiness and the experience of the Mashape community. 



Designing an API the Right Way Posted 1 year ago

Everyone and their dog’s are building API’s these days. Most new apps/services have some kind of API and almost every app uses at least one API. I was hacking on a project a couple of years back and I remember one of the dev’s on the project mentioning that we should have an API. At the time I thought he was crazy. We hadn’t even launched the product so why would anyone want to use our API, let alone our App. Our app eventually failed, mostly to ourselves. We out grew it, moved on to bigger and better ventures, but looking back he was right. We should have had an API. It may not have failed. 

When you start to build your API ask yourself, is your app going to be valuable to someone? Are you solving someone’s pain point or are you adding to the noise? API’s like Twillo, Stripe, Salesforce, Dropbox and Twitter add value to the world. Is your API going to be a service like Twillo or Stripe, where your core business providing core level functionality to someone else’s app? Are you going to build an app with the goal of having people add value to your product like Twitter. Someone will likely not want to use an API if it adds no value to the community/world.

A great API is planned and designed well. Two questions you should be asking your self when designing you API are, what are the goals or goal of this API and who will be using this API? You need to start asking yourself questions like what protocols and data formats are you going to us. How are you going to lock down your app? Open source framework or build it from the ground up? 

When it comes to approaches you have tons of options. You have REST, SOAP and XML-RPC just to name a few. The most popular in today’s APIs is REST. RESTful APIs are simple to use, and the amount of data you send is much smaller when commpared to SOAP. You also may want to base your choice on who your audience is? Some people may just love SOAP. Xnigte has 50+ financeAPIs and close to 5 billion+ calls each month. For data format you again have tons of choices but the main one again is going to be JSON.

Your API needs to be flexible. What makes an API flexible? It provides choices for data formats, protocols, and what version you want to use. Gives developers control of partial queries and updates, and batch operations. You offer advanced options like web hooks, streaming, and caching.

Something else you’ll want to keep in mind is what your Time to first “Hello World” is. You want to make it really easy for a developer who’s new to your platform to get up and running. There are a few way you can do that. Make it clear what you do.  Take Stripe’s home page for example.

You instantly know what the kind of problem the API solves, who it’s aimed at and what it does.  You also will want to offer a free or trail period. Get your users hooked, then sink your hooks into their wallets. Make it fast and easy to sign up. Again look at Stripe.

It’s so fast you can even skip over the signup process to get going. You need well organized and well written docs. They need to be clear and easy to understand. You are also going to want to have lots of examples of code, for as many languages as you can. The more you can people started in the right direction the better off you are. If you can provide tools to for a user to start playing with data then your even further along.

Your API needs to be managed. You need to mange things like security, key management, monitoring, reporting, scaling, rate limiting, and versioning. One other thing great API’s do is measure. Things like Traffic (total calls, top methods, call chains, quota faults), your service(Status), and your support, (tickets, response times, community metrics). These things can make or break your application.

Your going to want to provide great support. What makes your API supported? Great developer experience. This starts with the signup and includes everything from guides, to references, SDKs, to the pricing. Great support and evangelism teams that are active, engaged, listening, responding, and are at events. Your API needs to have communication and community in the forms of forums, a blog, social media, email support, and have an app gallery show casing the best.

Now you have the tools to build an amazing API go build it and add it to Mashape. ;-)

An open letter to developers. Pls stop fucking up the APIs ecosystem. Posted 1 year ago

Dear developers (API providers),

pls stop fucking up your public APIs.

Every week there is an API that is changing, being shutted down, or malfuctioning. If this trend will continue, we lose trust in using third party services via APIs and we’ll just go back to the old way and reinvent the wheel, by ourself.

Reliabilty and trust are the most important things for this ecosystem. 

We’re seeing an explosion of public APIs, so the trend is strong, but still fragile. 

"next time someone told me why I keep reinventing the wheel, is because the wheel does not work"

This is what I heard, from a developer few weeks back. And you know what? He’s right.  You can’t launch an API, get people relying on you, and then out of nowhere, you wake up and say:

sorry, we’re going to shut down this. Good luck!

Do you want some recent examples?

Twitter is fucking it up - multiple times. fucked up

Simplegeo fucked up

I think we’re at a inflection point. Go big or go home. The future of APIs can be: 

1) Third party APIs are going to be mainstream in the software development and they will become THE way we build software.


2) They will be left in the dust, because developers have lost trust.

The desitny is attached to all the API providers. The way they are going to RESPECT and MAINTAIN THEIR PROMISES to their developers is crucial, to define the future of this ecosystem. Do less fanfare when you launch an API and stay heads down and keep that API alive as much as you can. There are people that are investing their love and time on you.

Please stop play around, we trust you, we rely on you. Don’t fuck it up. 



CEO of Mashape