API and WebHooks Overage Pricing

adam's Avatar

adam

10 Apr, 2013 03:37 PM

API Call

In most cases, API calls to CheddarGetter occur fairly infrequently. Businesses who correctly integrate with our API, and use it as it was meant to be used, present a reasonable load on our server, and cause no problems. The cost of providing an API is just a cost of doing business, and we have no desire to charge any more than what is necessary to cover those costs. Most will never pay us directly for a single API call but in the case where a merchant’s usage of the API is significantly disproportionate to the amount of revenue we receive from that customer, we need to do something about it.

With API calls, there may be an additional charge for exceeding a set velocity or exceeding a set total number of API calls in a month. In each case, the limits will be set relative to, say, the number of revenue transactions in a month. We’re not yet doing this but plan to soon. First, we will begin tracking API call quantities and velocities to get a baseline measurement. Based on that data, we will determine what’s normal, then decide at what level to start charging. Our goal here is only to charge for usage well above the average so the vast majority of our customers will not be charged for API calls. Only those with an abnormally high usage will be charged. The fees, if any, will be nominal.

Web Hooks

As with API calls, CheddarGetter handles your web hooks with ease in most cases. However when your services hits a snag (something hangs), our service retries that hook multiple times, for multiple seconds each time. This, of course, is a good thing because it makes the hook system tolerant of failure of the listener to process the hook. This can cause significantly elevated usage of resources by our background processes, which can delay other customers' webhooks if there’s a backlog. This is bad juju, and we feel that good users should not bear the weight of those who are causing the problems.

Similar to API calls, we’re looking at setting some velocity and total limits as well as total time waited for listeners to respond. We’re not doing this yet but plan to soon. Again, only those with abnormally high usage of hooks will be affected.

  1. 1 Posted by tom on 12 Apr, 2013 09:43 PM

    tom's Avatar

    Hi CheddarGetter Team,

    Totally makes sense that you would want to charge based on number of api calls and webhooks.

    But your customers need a dashboard tab to tell them how many API requests and webhooks they are generating so they know if they are a problem or not.

    Also some ballpark on price would be nice. Is it something like Amazon's AWS pricing for SQS or S3 requests?

    Thanks for the great service. We are still really loving CheddarGetter.

    Regards,
    Tom

  2. Support Staff 2 Posted by Marc Guyer on 13 Apr, 2013 12:01 AM

    Marc Guyer's Avatar

    Tom -- Thanks very much for the feedback.

    Totally makes sense that you would want to charge based on number of api calls and webhooks.

    But your customers need a dashboard tab to tell them how many API requests and webhooks they are generating so they know if they are a problem or not.

    Agreed. We haven't even begun to track it yet. Once we do, those stats will be under the general settings -> billing page.

    Also some ballpark on price would be nice. Is it something like Amazon's AWS pricing for SQS or S3 requests?

    Right, something quite low. We'll also include a large initial block of free calls based on some multiple of your number of paid transactions. We'll decide later what that number is -- after we have a couple of months of data on the usage levels of the current customer base. I expect that more than the majority of our customers will never pay for a single request or hook. Again, this is just a way to control for significantly high usage well above the norm.

  3. Jess Pendley closed this discussion on 21 Nov, 2013 07:38 PM.

Discussions are closed to public comments.
If you need help with Cheddar please start a new discussion.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

28 Mar, 2024 10:45 PM
24 Jan, 2024 08:33 AM
11 Jan, 2024 07:13 AM
30 Nov, 2023 02:07 AM
22 Nov, 2023 08:41 AM