Charge based on CRUD operations?
Let's say, you have a service that is being used by different companies. Where their employees are constantly making CRUD operations, how would you charge them since of course everything costs. Now a company might have 500 employees while another one only have 50. Any suggestion would really help?
Sincerely
9 Replies
are you asking a general business model question, or are you asking how to charge the companies based on the number of API requests they make
Kind of both, but a way to track every requests so that I charge them for the amount of expenses.
Just enforce some sort of authentication and when you verify it; handle it there or as a follow-up Middleware
In regards to charging them no clue. Wouldn't go by employee as in any automation that wouldn't affect the amount of requests performed. Perhaps doing more invocations in a set date period would be a better business model
the usual setup is, you're going to give the company one API key to use for all their calls, and that key is attached to some company profile
company profile has attached payment info, and you can guess the rest
and just as an example, here's how it works with Stripe from the API caller's perspective: https://stripe.com/docs/api/authentication
Stripe API reference – Authentication – curl
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
and coincidentally, since you're charging money for your API, you can integrate with Stripe to facilitate your payments
they have support for subscriptions, metered billing, billing by number of licenses/seats, etc.
@SwaggerLife
and also https://stripe.com/docs/keys
API keys
Use API keys to authenticate API requests.
I see, thank you very much for the advice guys. That was really helpful. Sincerely.
Also, an alternative business model thought - you could be more like an ISP. Charge some flat fee for the service, or tiers, with different ratelimits. You charge them as if they were going to use the entire ratelimit, when in most cases they won't (though realistically you'd have to do some research and figure up a cost that gives a net profit in most situations while still being reasonable to those users). Sometimes the consumer would prefer a predictable cost vs pay-per-query which could quickly get out of hand
This also lets you make some guarantees; like if your ratelimits are 1/10th your server's capacity, you can guarantee that you can service at least 10 customers no matter what the customers are doing (and can probably get away with a lot more)