Our documentation has moved!

You are currently viewing a legacy version of our help articles.
For the most up-to-date version, please use the new Chargify Help & Support Site.
Follow

v1.7.4 (7/21/2011 ~4pm)

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

_Chargify__Web_Advocate___Production___Settings.png

We also refreshed the look and information in this template a bit, and updated the subject.

Chargify_Email.png


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!

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

4 Comments

  • 0
    Avatar
    Anthony Eden

    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.

  • 0
    Avatar
    Michael Klett

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

  • 0
    Avatar
    Tyrel Burton

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

  • 0
    Avatar
    Michael Klett

    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.

Please sign in to leave a comment.
Powered by Zendesk