Launch HN: Kable (YC W22) – All-in-one platform for API products
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...
83 comments
[ 2.8 ms ] story [ 200 ms ] threadWe'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.
Oh, come on
[edit] hidden at https://kable.stoplight.io/docs/kable/
In that case, I have to say no.
In the meantime, go to https://kable.stoplight.io/docs/kable/ (thanks mtmail!)
Just updated -- you should all have open access now. Really sorry about that!
Bad move for a developer focused product. Come on.
Footer works. Thanks
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
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.
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 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.
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.
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!
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.
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.
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).
Twilio monetizes 3 of their APIs on RapidAPI including the SMS API:
https://rapidapi.com/twilio/api/twilio-sms/
https://rapidapi.com/user/twilio
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).
This concerns me as a non-government agency. I hope vendor lock-in isn’t your business strategy.
The one you're replying to isn't op and is just taking a jab at enterprise pricing.
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.
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
How do you see yourself differentiating between Stripe billing?
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.
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.
We will always support customers who need to export data out of Kable into another system.
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 :)
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.