Forums/Announcements/Changelog
v1.7.4 (7/21/2011 ~4pm)
Michael Klett
posted this on July 21, 2011 04:13 pm
- Added an option so merchants can select whether or not they want to receive emails when there are new signups
- Changed the signup notification email subject from "New Subscription Signup for <site name> (via Chargify)" to "[Signup] <merchant name> - <site name>" (please update your filters, if you're so inclined)
- Added rate limit information to the API response headers
Choose whether or not you want to receive emails when your customer signs up
Before, this wasn't an option and you got the signup email no matter what. We've made this an option so if you're importing a bunch of customers, for example, you won't get an email for every one.
This option has been defaulted to "On" for all existing sites, but will default to "Off" for new sites.
We also refreshed the look and information in this template a bit, and updated the subject.
Rate limit information
We're preparing to release our formal API rate limiting program, and the first step is to let you know just how many requests you're making. We've added some new headers to the response to API requests to help with this:
- X-RateLimit-Limit: your daily limit
- X-RateLimit-Remaining: your daily remaining allotment
- X-RateLimit-Reset: a timestamp representing when your daily allotment resets (as an integer representing seconds since epoch)
We won't be blocking requests just because you get to 0 remaining (yet). And, we don't plan to ever block important requests like subscription signups. More details will be shared in the coming weeks!
Comments
What's the story behind the rate limiting? Are there specific API calls that will be limited and others that won't? It seems odd that a service designed for billing would implement any sort of rate limiting - it's not like Twitter where the data might be useful but not critical for most; on the contrary, data from payment systems is critical and rate limiting seems inappropriate.
For something like this it's really important for us, the merchants, to understand the backstory and to know exactly where the rate limiting might be applied. Right now this post just makes me nervous, which is not a feeling I like.
Sorry, didn't mean to alarm you. We'll be working hard to make sure that all critical data is always available. Right now we're mainly trying to enumerate usage, point out where people are making suboptimal use of the API, and make it easier to be able to regulate abuse. Believe me, it will be a net positive to make sure you can get at your data even when some test site is trying to cram down 1000s of requests per second...
Michael - is there any way to segment off test vs. production sites on your end? Seems odd you would be mixing Production and Test API calls together...
Tyrel: We're tracking calls based on site/subdomain, so we'll have the distinction between test and production. It will be a factor that we'll consider when limiting.