[HN Gopher] Launch HN: Kable (YC W22) - All-in-one platform for ...
___________________________________________________________________
Launch HN: Kable (YC W22) - All-in-one platform for API products
Hi HN! I'm Adam from Kable (https://kable.io). We make it easy to
build great 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 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!
Author : asommer12
Score : 143 points
Date : 2022-03-10 14:52 UTC (8 hours ago)
| jensneuse wrote:
| > Let's trade: Email address for API documentation
|
| In that case, I have to say no.
| [deleted]
| mtmail wrote:
| hidden at https://kable.stoplight.io/docs/kable/
| dang wrote:
| 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!)
| asommer12 wrote:
| 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!
| gondo wrote:
| How do you deal with taxes? Or how do you help your customers
| deal with taxes?
| asommer12 wrote:
| 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.
| searchableguy wrote:
| Is there a way to integrate paddle?
| asommer12 wrote:
| 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
| searchableguy wrote:
| Have any example on how to add kable to a graphql API?
| asommer12 wrote:
| 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.
| gondo wrote:
| I see. Stripe actually does not help with taxes at all. All
| the work is left for users to figure out, configure and file.
| asommer12 wrote:
| @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!
| asommer12 wrote:
| Ahh, are you talking about the actual setup of tax codes in
| Stripe?
| shaibruhis wrote:
| Congrats on the Launch Adam! Excited to incorporate Kable into
| our product :)
| throw03172019 wrote:
| > Let's trade: Email address for API documentation
|
| Bad move for a developer focused product. Come on.
| dang wrote:
| asommer12 wrote:
| Sorry about that! Site should be updated now, would love to
| hear your feedback
| throw03172019 wrote:
| Mobile menu link still goes to the name-email-wall page.
|
| Footer works. Thanks
| asommer12 wrote:
| Updated again, thank you :)
| andhikasudarman wrote:
| great product. goodluck!
| transitivebs wrote:
| 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
| asommer12 wrote:
| 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.
| GuillaumeSimard wrote:
| Congrats on the launch! How does that compare to using Stripe for
| charging customers?
| asommer12 wrote:
| 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_.
| DrBenCarson wrote:
| 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
| [deleted]
| asommer12 wrote:
| 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!
| bwood wrote:
| 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!
| azianmike wrote:
| Congrats on the launch!
|
| How do you see yourself differentiating between Stripe billing?
| asommer12 wrote:
| 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.
| wapxmas wrote:
| seandoh wrote:
| Happy to see where this has ended up. Congrats on the launch.
| averyyip wrote:
| Congrats on the launch Adam
| wluer wrote:
| Congrats on the launch! Kable has really simplified billing for
| us and it also doubles as a pretty great API usage analytics
| platform
| jacob_rezi wrote:
| This is a very webflow website
| camjw wrote:
| Is this a positive or a negative?
| aghilmort wrote:
| 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.
| asommer12 wrote:
| 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
| dylanbfox wrote:
| 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?
| asommer12 wrote:
| 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.
| Klonoar wrote:
| 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.
| asommer12 wrote:
| 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.
| rsstack wrote:
| > 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).
| GordonS wrote:
| Non-public pricing is something that _really_ grinds my
| gears...
| qorrect wrote:
| It's a big red flag for me too, I usually nope right out.
| Mandatum wrote:
| 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.
| asommer12 wrote:
| 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.
| fernandopj wrote:
| 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.
| asommer12 wrote:
| 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.
| fernandopj wrote:
| 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).
| hbcondo714 wrote:
| > 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
| echelon wrote:
| 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 :)
| asommer12 wrote:
| 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.
| tdfirth wrote:
| 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 :).
| nickgubbins wrote:
| Congrats on the launch! Looks awesome
| walterpintor wrote:
| Excited about Kable! Congrats on the launch!
| mhamann wrote:
| 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.
| mtmail wrote:
| > Let's trade: Email address for API documentation
|
| Oh, come on
|
| [edit] hidden at https://kable.stoplight.io/docs/kable/
| asommer12 wrote:
| Updated! Thanks for helping me catch that :)
| dang wrote:
| Yikes, sorry - I forgot to get that fixed. Adam has fixed it
| now. Thanks for pointing this out and digging up the correct
| link in the meantime.
| cofactrmh wrote:
| Congrats on the launch! We were looking for exactly this service
| at Cofactr and we're super pumped when we found Kable. Happy
| users!
| drewda wrote:
| 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.
| asommer12 wrote:
| 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.
| the_arun wrote:
| What happens if Kable service is down for some reason?
| asommer12 wrote:
| 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.
| abuehrle wrote:
| That's for usage, but aren't auth requests going to Kable
| too?
| asommer12 wrote:
| 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
___________________________________________________________________
(page generated 2022-03-10 23:00 UTC)