We’ve been closely monitoring things on rapid api over the last few days and have come to the decision to pull our API from the Rapid API platform.
If you’re a developer who is thinking obout using Rapid API, we hope this blog will help you make a decision.
This post will explain why we’re leaving RapidAPI, what our next steps will be, and what the timeline for this will be.
So first we’ll jump into the issues we’re faced with RapidAPI.
This is rough. There are multiple reports online about RapidAPI not supporting API creators with billing issues, overage issues and many more. This is a problem, but we haven’t experiences to much of this.
What is a real problem are the terms in which a creator gets paid. You get a notification immediately when a user subscribes to a plan (nice, but the bare minimum i expect) but then you won’t receive payment for at LEAST 30 days, probably more like 45.
On the platform there is an expected date that a payment should be paid out, but you can expect that date to breeze by without any money hitting your Paypal account.
And if a user doesn’t make a payment or payment fails? Well, don’t expect any email updates or meaningful notes on that users profile. It’ll just be stuck on ‘pending’ until they eventually get booted from your API.
We’ve even have a few other API owners contact us to see if we actually get payouts!
This needs improvement for the Rapid platform to be sustainable for small devs.
We have quite a few users, thank you everyone for using the API and your support. I wish it was easier to view how you are using the API, what requests you are making, how you are triggering errors and anything else we deem worth tracking.
The rapid platform is soooooooooooooo slow. It takes an age to load our user list. And sorting the users by data? No chance! On the user table, it shows how many requests a user has made in the last 60 days which I think is a great metric to have ‘at a glance’.
Unfortunately, You can’t even sort by this metric on the users table! So you want to find whos made the most requests via your users table? Enjoy working though 50 users at a time page by page.
You can get some very good data from the analytics page, but this is limited to 30 days (not a deal breaker).
Everything feels half-baked.
It would be really nice to be able to perform bulk actions on users to do things like inviting users to a private plan, blocking access or doing anything else really.
Our most wished for feature is being able to bulk message users.
I get it, a rapid api customer isn’t our customer, it’s rapid APIs. Saying that, i’d love to be able to fire out a message if we have an outage, a bug, a new feature/blog or a special offer.
When you’ve got any more than 30 users, mailing individually just isn’t an option.
Even if an API developer could only send one mass-message out per month, that would be a huge improvement.
This is a super annoying feature/bug. Say you’re trying to do some testing with your free plan to hit the sweet spot of how to give enough access to tempt your platform but not too much that they never sign up.
As you try different scenarios, rate limits and access to different endpoints - your users WILL NOT be updated with your changes.
If you start with 100 free requests per day and want to lower it to 20? That limit of 20 will be in effect for all your new users, but all your old users? Yeah, they still get 100 requests.
Guess what you have to do to resolve this… block them.
And before you block them, you think, blimey… I should send an email to customer support about this!
Don’t expect a reply from rapid API… I’m still waiting for mine!
There isn’t a competitor for rapid API is there? If you know of one, please email us! We’re looking into rolling our own user management and billing tools. We really don’t want to do this.
The only other option is making the API totally free and setting up a membership plan on buy me a coffee. If anyone has any better ideas, please send an email our way.
We won’t be making any rash changes. We’ll be giving at least 90 days of notice before we turn off any rapid api endpoints. Endpoints and queries won’t change.
We’ll blog again soon about what we decide to do.
-pAPI Team
p.s. We killed our own homepage! Was this on purpose, kinda. We wanted to run an experiment to see if people would use our API key to grab data from the API, then see if when we pull the key, these people would then buy a licence. It’s too early to call yet, but when we get round to it, we’ll get our pornstar index working again.