This company/team distinction describes what we're looking for next in our implementation :)

Also, hey, I'm Adam, a very happy customer of PropelAuth at Kable.io. Andrew is an incredibly responsive founder, who has been a great partner in the launch of our own B2B business. High recommend from me -- PropelAuth rules

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.

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.

Of course! Our mission is to support developers building great products. Our goal is to help you grow, not hold you prisoner

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.

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

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!

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.

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 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.

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.

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.

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.

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

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.

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

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.

Updated again, thank you :)

Ahh, are you talking about the actual setup of tax codes in Stripe?

@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!