Launch HN: Kable (YC W22) – All-in-one platform for API products
83 comments
Great to see a new option!
Apigee and Mulesoft went "enterprise." AWS API Gateway and GCP Endpoints kind of stagnated. Seems like the only option for small and medium-sized SaaS businesses that want to sell access to APIs is to roll their own or fully commit to RapidAPI. (Please let me know other options I am forgetting or not aware of!)
We currently "roll our own" using Kong, Auth0, and a Rails app. Not sure if we'd want to outsource all of those components. But will keep an eye on this option for the future, particularly for doing metered billing.
Apigee and Mulesoft went "enterprise." AWS API Gateway and GCP Endpoints kind of stagnated. Seems like the only option for small and medium-sized SaaS businesses that want to sell access to APIs is to roll their own or fully commit to RapidAPI. (Please let me know other options I am forgetting or not aware of!)
We currently "roll our own" using Kong, Auth0, and a Rails app. Not sure if we'd want to outsource all of those components. But will keep an eye on this option for the future, particularly for doing metered billing.
This comment encapsulates the inspiration behind Kable beautifully.
Developers I've spoken with have struggled to get up and running with AWS API Gateway or GCP Endpoints. They each had plans to evolve their pricing model based on business-specific metrics (like monthly active users, transactions processed, or requests to specific APIs), and they weren't able to get the per-contract or per-endpoint pricing flexibility out of these offerings that they wanted.
Kable's greatest strength is its usage metering and billing. Not every developer is going to need to outsource their entire API gateway, and that's alright. In the early days, this does help get to market faster. At scale, though, when billing becomes more and more complex, is where Kable's greatest strengths in billing shine.
Developers I've spoken with have struggled to get up and running with AWS API Gateway or GCP Endpoints. They each had plans to evolve their pricing model based on business-specific metrics (like monthly active users, transactions processed, or requests to specific APIs), and they weren't able to get the per-contract or per-endpoint pricing flexibility out of these offerings that they wanted.
Kable's greatest strength is its usage metering and billing. Not every developer is going to need to outsource their entire API gateway, and that's alright. In the early days, this does help get to market faster. At scale, though, when billing becomes more and more complex, is where Kable's greatest strengths in billing shine.
I'm the founder of Saasify, a similar platform from a few years back. Love what you guys are doing, though I think you may run into some of the same issues that we ran into. Here's our post-mortem that you'll hopefully find helpful https://transitivebullsh.it/saasify-vc-feedback
Great feedback, thank you. From what I can gather, the biggest differences between Kable and Saasify are the target market and core focus. Where Saasify is focused on micro SaaS projects, Kable is aimed at helping the growing population of API-first businesses. And from a core focus perspective, where Saasify is focused on a wide range of developer needs (user accounts, marketing sites, documentation, etc), Kable is focused on the core elements of an API business: authentication, metrics, and billing. But there's definitely a good amount of similarity here, and I love to meet folks building in a similar space.
Immediately what I thought -- when your users become successful, they will churn. Ideally you want the opposite of that (expansion from successful users).
> Our pricing is pay-as-you-go based on the volume of events we store and the revenue we help our customers generate. That means we get to dogfood our own software for usage-based billing!
So what is your pricing? The website says "starting at $200 / month", but before I go to sign up and try to integrate, I'd like to be able to estimate if it'd be $200/mo for my company or $2,000/mo.
P.S.: I signed up, even got to a notice that tells me I can't go live without entering credit card details - but still no details on pricing.
P.P.S.: Sorry that it reads like a negative comment. I think it's great and I might actually end up using it, but not before I know if it fits our budget (and if it's worth my time).
So what is your pricing? The website says "starting at $200 / month", but before I go to sign up and try to integrate, I'd like to be able to estimate if it'd be $200/mo for my company or $2,000/mo.
P.S.: I signed up, even got to a notice that tells me I can't go live without entering credit card details - but still no details on pricing.
P.P.S.: Sorry that it reads like a negative comment. I think it's great and I might actually end up using it, but not before I know if it fits our budget (and if it's worth my time).
Non-public pricing is something that really grinds my gears...
Because it's Enterprise pricing. We price based on your company. If your logo is big enough, we'll give you cost price because we'll use you as a marketing tool. If you're a government client, we'll give it to you cheap enough to get a foothold in your organisation, then pull in massive deals over years and take away discounts once it's too hard to get rid of us. If you're some random company, you get sticker price - but we can't publish that because most of our revenue comes from large Enterprise who all get custom, MNDA-protected pricing.
> If you're a government client, we'll give it to you cheap enough to get a foothold in your organisation, then pull in massive deals over years and take away discounts once it's too hard to get rid of us.
This concerns me as a non-government agency. I hope vendor lock-in isn’t your business strategy.
This concerns me as a non-government agency. I hope vendor lock-in isn’t your business strategy.
Just making it clear for others as I had to double check.
The one you're replying to isn't op and is just taking a jab at enterprise pricing.
The one you're replying to isn't op and is just taking a jab at enterprise pricing.
The goal here is definitely not a lock-in strategy. Our lack of clear pricing is simply the nature of being a brand new company who hasn't yet had sufficient time to work with customers to solidify the right price point. As we iron out our business model we'll absolutely make pricing more transparent on our site.
It's a big red flag for me too, I usually nope right out.
The truth is that we're still iterating on our pricing model which is why it's somewhat vague on our website. We offer a few different pricing tiers that range from Free to $200/month to $800/month depending on your revenue and usage of the platform before Enterprise. If you handle very heavy traffic (millions of events recorded daily), we'll help build a pricing plan that makes sense for your business.
Congrats on the launch, Adam!
We're using Kable at Rownd to better understand how our customers use our authentication and account management services. For example, we can track how many sign-ins a particular customer is driving through their website and whether their users typically use email or SMS to sign up. Eventually, we'll be able to use this data to bill our usage-based customers for their volume.
Overall, implementation was about as simple as stated above. In our Node.js backend, we imported the Kable library, created an instance with our tenant config, and then added one line to the API methods we wanted to record.
We're using Kable at Rownd to better understand how our customers use our authentication and account management services. For example, we can track how many sign-ins a particular customer is driving through their website and whether their users typically use email or SMS to sign up. Eventually, we'll be able to use this data to bill our usage-based customers for their volume.
Overall, implementation was about as simple as stated above. In our Node.js backend, we imported the Kable library, created an instance with our tenant config, and then added one line to the API methods we wanted to record.
Kable has been super helpful for my company so far! Our billing is pretty complicated because it's usage-based and we're customizing pricing for every single customer at this point.
The integration with Kable was very simple, took like 15 minutes to get a basic implementation working. It fires "billing events" automatically and then these can be applied to custom pricing options for every customer.
Love it!
The integration with Kable was very simple, took like 15 minutes to get a basic implementation working. It fires "billing events" automatically and then these can be applied to custom pricing options for every customer.
Love it!
Wish you all the best so wanted to share a bug: https://imgur.com/a/2kr81fH
Your web app is probably burning a lot of unnecessary render cycles as a side effect of this behavior as well
Your web app is probably burning a lot of unnecessary render cycles as a side effect of this behavior as well
Thanks for the report!
That page is actually hosted by one of our partners, PropelAuth, who manages end user authentication for access our dashboard. (End user login wasn't core to our business at Kable, so we found a partner who could manage this for us.)
Highly recommend PropelAuth for anyone looking for user authentication, they've been an amazing partner!
That page is actually hosted by one of our partners, PropelAuth, who manages end user authentication for access our dashboard. (End user login wasn't core to our business at Kable, so we found a partner who could manage this for us.)
Highly recommend PropelAuth for anyone looking for user authentication, they've been an amazing partner!
Awesome unfortunately this isn’t exactly the best foot forward for them but that great to hear.
[deleted]
Congrats on the launch. Very appealing product.
I thought RapidAPI.com would be a direct competitor, but their site changed a lot. Have they pivoted from monetizing an API, directly? If so, then I'd definitely keep Kable on my radar.
I thought RapidAPI.com would be a direct competitor, but their site changed a lot. Have they pivoted from monetizing an API, directly? If so, then I'd definitely keep Kable on my radar.
RapidAPI does offer some of the tools that Kable offers. And if you're looking to monetize a single REST endpoint, RapidAPI is probably the right tool for the job.
Kable is infrastructure for API companies, brands, and larger projects. You wouldn't find Twilio's SMS API in RapidAPI's marketplace, nor would you find many of today's hottest new API-first companies. Kable's mission is to help those companies launch quickly and scale.
Kable is infrastructure for API companies, brands, and larger projects. You wouldn't find Twilio's SMS API in RapidAPI's marketplace, nor would you find many of today's hottest new API-first companies. Kable's mission is to help those companies launch quickly and scale.
> You wouldn't find Twilio's SMS API in RapidAPI's marketplace
Twilio monetizes 3 of their APIs on RapidAPI including the SMS API:
https://rapidapi.com/twilio/api/twilio-sms/
https://rapidapi.com/user/twilio
Twilio monetizes 3 of their APIs on RapidAPI including the SMS API:
https://rapidapi.com/twilio/api/twilio-sms/
https://rapidapi.com/user/twilio
Oh, I bought the vision. I'm impressed with what's available at launch, even.
Personally, yes, I'm much more aligned with Kable value proposition. It solves pain points I have today and by experience (authentication schemes, how to throttle calls, how to monitor etc).
Personally, yes, I'm much more aligned with Kable value proposition. It solves pain points I have today and by experience (authentication schemes, how to throttle calls, how to monitor etc).
How do you deal with taxes? Or how do you help your customers deal with taxes?
As of today, Kable relies on our payment partners to calculate tax.
If you connect your Stripe account to Kable, you can enable automatic tax calculation in your Stripe dashboard, and invoices generated by Kable will be taxed by Stripe. As we add other payment partners, we will follow the same pattern. In the future, though, we do plan to add the option to calculate taxes directly within Kable.
If you connect your Stripe account to Kable, you can enable automatic tax calculation in your Stripe dashboard, and invoices generated by Kable will be taxed by Stripe. As we add other payment partners, we will follow the same pattern. In the future, though, we do plan to add the option to calculate taxes directly within Kable.
I see. Stripe actually does not help with taxes at all. All the work is left for users to figure out, configure and file.
@gondo I think this was a relatively recent change by Stripe. Check out Stripe Tax -- https://stripe.com/docs/tax/invoicing
Kable uses Stripe's Invoice API directly (we don't create Stripe subscriptions which would cost an extra 0.5%). You can set up Stripe Tax to work with Invoices, and I believe most of what you'd want happens automatically.
I may be wrong though -- please let me know if you've had a different experience!
Kable uses Stripe's Invoice API directly (we don't create Stripe subscriptions which would cost an extra 0.5%). You can set up Stripe Tax to work with Invoices, and I believe most of what you'd want happens automatically.
I may be wrong though -- please let me know if you've had a different experience!
Ahh, are you talking about the actual setup of tax codes in Stripe?
Is there a way to integrate paddle?
Integrating Paddle (and other payment providers) is in our plans for the spring. Our existing customers have skewed toward Stripe, so we started there. If you're using Paddle today and want to get started with Kable, let me know and we can chat about prioritizing Paddle sooner
Have any example on how to add kable to a graphql API?
We don't currently have any customers using Kable and GraphQL together. To be totally honest, I'm not a GraphQL expert, and I don't want to give you any false information, so unfortunately no, I don't have an example for you.
Kable can be accessed through our Node and Python libraries (more languages on the way) or over HTTPS REST API. I will have to defer to your design sense about the best way to leverage these technologies with a GraphQL API today.
Kable can be accessed through our Node and Python libraries (more languages on the way) or over HTTPS REST API. I will have to defer to your design sense about the best way to leverage these technologies with a GraphQL API today.
One of the problems with graphql is a single query can fetch your entire API.
This means to record for billing, you would need to parse the AST and tag the parts as well as their associated cost in a query.
It's not an easy drop in, unfortunately.
This means to record for billing, you would need to parse the AST and tag the parts as well as their associated cost in a query.
It's not an easy drop in, unfortunately.
This totally solves something I don't want to have to build at this stage! I hacked together a garbage API key system that has nothing to do with my platform's core competencies.
Your offering is so full of useful functionality, too. Reports, metering, ... so much good. I could totally see this becoming a Twilio or Stripe for APIs.
Really, really awesome. Congrats! I'll be looking to sign up soon.
Edit: my platform is built in Rust and I don't expect you to have an SDK for that anytime soon (I'm off the beaten path). I'll see what your API looks like :)
Your offering is so full of useful functionality, too. Reports, metering, ... so much good. I could totally see this becoming a Twilio or Stripe for APIs.
Really, really awesome. Congrats! I'll be looking to sign up soon.
Edit: my platform is built in Rust and I don't expect you to have an SDK for that anytime soon (I'm off the beaten path). I'll see what your API looks like :)
Hey, glad to hear it!
You're actually not the first person who's asked for a Rust SDK. This is something that is already in our plans for the near future.
In the meantime, all of Kable can be accessed via HTTPS REST endpoints. I wouldn't recommend using Kable for authentication over REST due to the potential latency issues it could cause for your API. But all of our functionality around pricing, metering, billing, and invoicing can be accessed directly, even without a Rust library.
Check out our documentation for a closer look at the REST API. Would be happy to chat some more over email to help you get started until our Rust library is available.
You're actually not the first person who's asked for a Rust SDK. This is something that is already in our plans for the near future.
In the meantime, all of Kable can be accessed via HTTPS REST endpoints. I wouldn't recommend using Kable for authentication over REST due to the potential latency issues it could cause for your API. But all of our functionality around pricing, metering, billing, and invoicing can be accessed directly, even without a Rust library.
Check out our documentation for a closer look at the REST API. Would be happy to chat some more over email to help you get started until our Rust library is available.
Hey, this is awesome.
I was working on a little API project this weekend[0] and struggling with how I was going to do authentication. Then I saw this post, and it took me about 10 minutes to add Kable and have it 100% working in my code.
Nice work!
[0] https://github.com/mjirv/dbt-metrics-api
I was working on a little API project this weekend[0] and struggling with how I was going to do authentication. Then I saw this post, and it took me about 10 minutes to add Kable and have it 100% working in my code.
Nice work!
[0] https://github.com/mjirv/dbt-metrics-api
Looks interesting! Do you guys offer any sort of visibility tools/reports into customer usage of different endpoints, tracking of actual API requests (including payloads/etc) per request, etc? Is it possible to use you guys just for billing if we already have our own auth?
Hey Dylan! A bit more context on each of your questions:
With regard to endpoint visibility, yes, totally. One of our strengths is the ability to even price different endpoints differently. If you have endpoints that are high-value that you want to track differently than other endpoints, you can simply tag it, and Kable will monitor that endpoint as its own dimension. So yes, you can see which customers are calling which endpoints through our dashboard.
With regard to tracking request payloads, this is something we do not currently support. We've given this some thought, and while we might change our position in the future based on customer feedback, we are currently not storing customer request data. The reason for this is privacy. We want to be careful about what information we store from our customers' customers, so we require developers to explicitly define what information gets recorded in Kable.
Finally, with respect to billing and analytics and authentication as separate features or products: *ABSOLUTELY*. You can use Kable for billing and analytics without using Kable authentication. We want it to be super easy to use both, but we understand many customers have other systems for managing API keys or other parts of the stack. In this case, we recommend using Kable's `record` method, and using us for our core competencies of billing and analytics.
With regard to endpoint visibility, yes, totally. One of our strengths is the ability to even price different endpoints differently. If you have endpoints that are high-value that you want to track differently than other endpoints, you can simply tag it, and Kable will monitor that endpoint as its own dimension. So yes, you can see which customers are calling which endpoints through our dashboard.
With regard to tracking request payloads, this is something we do not currently support. We've given this some thought, and while we might change our position in the future based on customer feedback, we are currently not storing customer request data. The reason for this is privacy. We want to be careful about what information we store from our customers' customers, so we require developers to explicitly define what information gets recorded in Kable.
Finally, with respect to billing and analytics and authentication as separate features or products: *ABSOLUTELY*. You can use Kable for billing and analytics without using Kable authentication. We want it to be super easy to use both, but we understand many customers have other systems for managing API keys or other parts of the stack. In this case, we recommend using Kable's `record` method, and using us for our core competencies of billing and analytics.
> Let's trade: Email address for API documentation
In that case, I have to say no.
In that case, I have to say no.
Sorry everyone! A lingering remnant gathering feedback from my pre-launch, apologies!
Just updated -- you should all have open access now. Really sorry about that!
Just updated -- you should all have open access now. Really sorry about that!
Argh! this was my mistake. I saw it and then forgot to tell Adam we needed to fix that before the launch. Sorry everyone! We'll get it fixed.
In the meantime, go to https://kable.stoplight.io/docs/kable/ (thanks mtmail!)
In the meantime, go to https://kable.stoplight.io/docs/kable/ (thanks mtmail!)
[deleted]
What happens if Kable service is down for some reason?
Great question. Our libraries are set up to handle Kable failures.
When a library request to Kable's server fails, dropped events will be logged as JSON for later processing. The Kable API is designed to handle backfilling of events, so if Kable ever goes down, we'll help you catch up on events that weren't recorded in real-time.
When a library request to Kable's server fails, dropped events will be logged as JSON for later processing. The Kable API is designed to handle backfilling of events, so if Kable ever goes down, we'll help you catch up on events that weren't recorded in real-time.
That's for usage, but aren't auth requests going to Kable too?
Yes, if you are using Kable for authentication, this is a larger problem but there are some fallbacks in place as well.
Our libraries cache the valid (and invalid) keys we process. So if Kable goes down, users with steady traffic (whose keys remain cached) will remain unaffected. Users who have not yet had a key validated by Kable, though, will experience problems while Kable restarts.
We have redundancies in place to ensure that Kable downtime is minimized. Obviously no system is perfect, and outages can't be avoided 100%. But we employ all best practices around redundancies, rolling deployments, and rapid response to minimize the impacts of downtime
Our libraries cache the valid (and invalid) keys we process. So if Kable goes down, users with steady traffic (whose keys remain cached) will remain unaffected. Users who have not yet had a key validated by Kable, though, will experience problems while Kable restarts.
We have redundancies in place to ensure that Kable downtime is minimized. Obviously no system is perfect, and outages can't be avoided 100%. But we employ all best practices around redundancies, rolling deployments, and rapid response to minimize the impacts of downtime
could be interesting if you added the option to also integrate their API with API aggregators -- write their integromate, zapier, pathfix, other blocks -- or at least give templates -- even templates would be good organic content:
- how to add your API to Zapier - how to add your API to Integromat or whatever their new name (?) is - rinse & repeat for all the other fabrics - pathfix, mulesoft, etc.
- how to add your API to Zapier - how to add your API to Integromat or whatever their new name (?) is - rinse & repeat for all the other fabrics - pathfix, mulesoft, etc.
Amazing idea, and actually something we're actively developing.
Soon you'll be able to connect Kable to any of your other data sources through Segment. Then, if your application is hooked up to services like Zapier, Amplitude, Mixpanel, etc, you'll be able to funnel data into Kable for billing purposes with no additional code.
Our goal here is to make it super easy to use Kable for billing no matter what your existing stack looks like
Soon you'll be able to connect Kable to any of your other data sources through Segment. Then, if your application is hooked up to services like Zapier, Amplitude, Mixpanel, etc, you'll be able to funnel data into Kable for billing purposes with no additional code.
Our goal here is to make it super easy to use Kable for billing no matter what your existing stack looks like
yes, my core thought was:
1. your current value prop is help users build API
2. value add is help them get distro for same API by abstracting away having their team deal with writing Zapier blocks, get into app stores for same, etc.
3. doing (2) is a long road, so could kickstart that with organic content for now, since a natural question after build API is ok, how do I get our block on their app store, same for integromat, mulesoft, etc.
1. your current value prop is help users build API
2. value add is help them get distro for same API by abstracting away having their team deal with writing Zapier blocks, get into app stores for same, etc.
3. doing (2) is a long road, so could kickstart that with organic content for now, since a natural question after build API is ok, how do I get our block on their app store, same for integromat, mulesoft, etc.
Congrats on the launch!
We were looking for exactly this service at Cofactr and we're super pumped when we found Kable. Happy users!
What’s the story for exporting data look like? E.g if I started with you but then wanted to migrate to a home grown solution.
There are a variety of different storage formats behind the curtain at Kable. Some things (like stored invoices) are trivial to export. Others (like full request histories) might be a bit more complicated. That said, we never want to lock you in.
We will always support customers who need to export data out of Kable into another system.
We will always support customers who need to export data out of Kable into another system.
Congrats with the launch. Excited to try this for our usage pricing invoicing later this year!
Congrats on the launch! Looks awesome
Congrats on the launch!
How does that compare to using Stripe for charging customers?
Great question! Kable is integrated with Stripe directly, so the migration from Stripe subscriptions to Kable is easy. We use Stripe Connect, so invoices generated on Kable reach your customers at their same payment method on file through your Stripe account.
Congrats on the Launch Adam! Excited to incorporate Kable into our product :)
Congrats on the launch!
How do you see yourself differentiating between Stripe billing?
How do you see yourself differentiating between Stripe billing?
Ahh, a question I get a lot, thank you for asking :)
Stripe is a payments company -- they are great at payments. They offer a full suite of tools (like subscriptions) around payments. But this is not their core competency.
Usage-based billing has three core components: * Defining pricing plans * Metering usage to generate invoices * Processing payments
Stripe is great at processing payments. But when it comes to defining usage-based pricing plans, and especially when it comes to metering usage, Stripe is actually pretty weak.
Pricing in Stripe is pretty brittle. You create products which have price IDs, and your code needs to understand these concepts. To evolve pricing for a customer, or to define a new pricing plan for an enterprise contract can be a pretty tricky thing to do.
And streaming usage data into Stripe is actually something that Stripe's docs recommends against. They recommend you aggregate your own usage metrics and post them infrequently into Stripe. Again, payments processing, not usage metering.
Kable's sweet spot as it pertains to billing is the first two items in that list. Pricing plans are super easy to define, manage, and evolve in Kable. Usage metering is our core competency. You don't need pricing concepts or external identifiers in your code. You record the *core concepts from your app* and Kable handles the rest.
Stripe is a payments company -- they are great at payments. They offer a full suite of tools (like subscriptions) around payments. But this is not their core competency.
Usage-based billing has three core components: * Defining pricing plans * Metering usage to generate invoices * Processing payments
Stripe is great at processing payments. But when it comes to defining usage-based pricing plans, and especially when it comes to metering usage, Stripe is actually pretty weak.
Pricing in Stripe is pretty brittle. You create products which have price IDs, and your code needs to understand these concepts. To evolve pricing for a customer, or to define a new pricing plan for an enterprise contract can be a pretty tricky thing to do.
And streaming usage data into Stripe is actually something that Stripe's docs recommends against. They recommend you aggregate your own usage metrics and post them infrequently into Stripe. Again, payments processing, not usage metering.
Kable's sweet spot as it pertains to billing is the first two items in that list. Pricing plans are super easy to define, manage, and evolve in Kable. Usage metering is our core competency. You don't need pricing concepts or external identifiers in your code. You record the *core concepts from your app* and Kable handles the rest.
Happy to see where this has ended up. Congrats on the launch.
Excited about Kable! Congrats on the launch!
Congratulations on your launch!
This is a very webflow website
Is this a positive or a negative?
Sorry Hackernews doesn't do a good job with comment reply notifications.
In this case, as a YC company, it is negative. It's using a template's UI as their own which is pretty incompetent IMO.
https://unicorns-webflow-html-website-template.webflow.io/ho...
https://www.kable.io/
This would be invisible to most people but it shows me a huge gap operational ability
In this case, as a YC company, it is negative. It's using a template's UI as their own which is pretty incompetent IMO.
https://unicorns-webflow-html-website-template.webflow.io/ho...
https://www.kable.io/
This would be invisible to most people but it shows me a huge gap operational ability
Congrats on the launch Adam
"We require a credit card on file before provisioning live API keys"
Err no thanks.
Err no thanks.
Our Test environment offers all of the functionality that our Live environment offers. You can get the entire Kable experience in the Test environment without registering a credit card. Only when you're ready to deploy Kable to your Live production environment do we require a payment method.
great product. goodluck!
Congrats on the launch! It's a bit early for me to try out something like this but I'm keen on exploring a usage based pricing model for my product... I'll come knocking when the time is right :).
> Let's trade: Email address for API documentation
Oh, come on
[edit] hidden at https://kable.stoplight.io/docs/kable/
Oh, come on
[edit] hidden at https://kable.stoplight.io/docs/kable/
> Let's trade: Email address for API documentation
Bad move for a developer focused product. Come on.
Bad move for a developer focused product. Come on.
Sorry about that! Site should be updated now, would love to hear your feedback
Mobile menu link still goes to the name-email-wall page.
Footer works. Thanks
Footer works. Thanks
Updated again, thank you :)
Congrats on the launch! Kable has really simplified billing for us and it also doubles as a pretty great API usage analytics platform
Kable takes care of all of the things that pull you away from your core business – API keys and authentication, usage-metering and billing, invoicing your customers, dashboards for tracking key metrics, evolving pricing to optimize revenue, surfacing usage dashboards to your customers – so you can focus on what’s most important.
Every API developer has to deal with important but unsexy responsibilities like “How will I securely manage API keys?” “How am I going to track which customers are using which parts of my product?” “How am I going to monitor usage of my API, and how can I make that information available to customers?” “Billing is complicated, invoicing is time-consuming, when am I going to find time to automate that?” This is the stuff we take care of.
I led the billing team at Hulu for five years and got a full education in the complexities of billing, payments, and accounting. Before that, I led the security team at Appian for two years, and before that I worked at WePay (YC S09), a payments API company. On a slightly weirder note...I have an obsession with API-first companies. I am fascinated by the rise of the API economy. Twilio for messaging; Stripe for payments; Algolia for search; Segment for data; the list gets longer every year. I have always been fascinated by these companies, wanted to work with them, learn from them, and serve them.
I spoke to hundreds of people building API companies and two themes rang more loudly than anything else: “We are doing X for now but we really want to do Y...” and “We haven’t built Z yet because we just don’t have the time.” These statements were always about the same topics, too: billing, invoicing, authentication, monitoring, analytics. Why was every startup struggling with the same things? I decided the best way to serve this community – a community I love – was to build tools for it all. Kable provides all the infrastructure you’d build in-house if you had all the time you needed.
The truth is, tools already exist for most of these things. So why wasn’t there wider adoption among the startup community? The answer, I learned, is pretty simple: integrating with third parties can be complicated and time-consuming. The key insight for Kable, therefore, is: it has to be trivial.
Kable can be added to any application with just three lines of code: import, configure, execute. We don’t depend on you storing external keys, nor do we require weeks-long technical integration to get onboarded. You can sign up, add us to your API, configure pricing plans, set up invoicing, and visualize your customers' usage through our dashboard – all in about 15 minutes.
Many of our first customers are other startups in our YC batch. They have been able to bring their products to market faster by outsourcing things like authentication. Right from launch they have clear visibility into their customers’ usage patterns. They don’t need to manually invoice their customers, and not only that, but having built on our infrastructure, they’re ready to tune their pricing models to optimize revenue without ever writing a line of billing code. With all this, startups can move faster than was previously possible.
Our pricing is pay-as-you-go based on the volume of events we store and the revenue we help our customers generate. That means we get to dogfood our own software for usage-based billing!
We’d love for you to try it out. You can sign up at https://kable.io and begin using our test environment for free. We require a credit card on file before provisioning live API keys, but the product is fully accessible to new users.
It’s so exciting for me to share what we’ve been working on with the HN community. You are the developers we hope to serve, and I’d love to hear your thoughts. Have you ever built an API? Ever struggled with pricing? Ever spent one too many hours setting up a dashboard? Ever thought to yourself “I wish I could just focus on my product?” We want to hear your stories. Kable was built for you, so please tell us what you think!