Mashery Quotas: Calls per "day" or calls per "24-hours"? - mashery

I am accessing an API hosted by Mashery with the following rate limit:
5 calls per second
10,000 calls per day
Does that imply that I can make 10,000 requests at 6:00PM, and then make another 10,000 requests at midnight? Or, does it mean I can only make 10,000 requests within any 24-hour period?
For example, does it mean that if I make 10,000 requests between 6:00PM one day, and 6:00PM the next, that I have to wait until 6:00:01PM before I can make another request. And then, at most I can make requests at the same rate I made the day prior (as the 24-hour period continuously shifts)?
I apologize if this is off-topic. I have a support request in for clarification, but I don't think they'll get back to me any time soon, and I figured that someone here would be familiar with the limits.

The limit is set per Calendar date and resets every midnight GMT time.
So for example if you made 10,000 calls at 6pm pacific (which is 2am GMT) you would have to wait 22 hours until 4pm pacific (which is midnight GMT) until you can start using your next batch of 10,000 daily calls.
Hope that answers your question.
Thanks,
Shai Simchi
Mashery Customer Support

Related

Implementing API throttling with RDB

I would like to implement this API throttling:
A user can only execute the operation once per minute (once executed, following requests will be rejected for 1 minute)
The expected total number of requests from all users is around 2 per second.
I am using PostgreSQL 14.5.
I guess I will need a table for exclusive processing. What kind of SQL/algorithm should I use?
You could store the latest accepted timestamp in a column. Every time a request is processed, the code could check if the interval between the current timestamp and the last accepted timestamp is less than a minute and reject if so.

Can interarrival time be used with anylogic schedule block?

I'm trying to model a production sequence in anylogic where orders should come in with an interarrival time of normal(8,105) seconds. These orders should come in every week day between 11 am and 2 pm (3 hour window).
I tried to implement this with the Schedule block in anylogic but this only allows me to define a rate per hour. Is there a way to do this with interarrival time?
Also the agents that arrive at 1:59 pm should also be processed even if it takes until after 2 pm. Is there a way to calculate the mean working time per day (the time from the generation of the first agent by the source block until the last generated agent enters the sink block)?
Thank you all in advance!
I would use the getHour() function and dispose of the agents if hour is not between 11 and 14. And inside the source you don't need to do anything special. If it even arrives at 11.59 pm it will be processed.

How exactly does the "Honor Period" work?

PayPal describes a "Honor Period" that lasts for 3 days after you authorize or reauthorize a payment, up until 29 days after the first authorization. The docs don't really go into very much detail about this honor period though, just that you should capture within it and that you can restart an expired honor period by reauthorizing.
I have 3 main questions:
When does the honor period start/end exactly? Is it an exact 72 hour window, to the second, from when you auth/reauth? Does it roll over at midnight or something instead? If so, what timezone?
What is the preferred/recommended way to determine if the honor period for an authorization has expired or else determine the expiration time in the first place? Authorizations have a expiration_time field which marks the end of the 29 day window that an authorization is valid for. Is there a similar explicit time field for the honor period? Is it simply based on the update_time field on the latest auth/reauth?
Is there a way to reauthorize before the previous authorization expires? Or more specifically, is there some way to ensure that the payment is always in an honor period, and that there is zero risk of some issue occurring because their funds weren't being held for a short amount of time before we reauthorized them?
The honor period begins the moment a transaction is created and generally lasts 3 days. During this time, captures will generally succeed. During this time, the amount is generally reserved on the customer's funding source, which may be a credit or debit card, meaning they cannot spend it on other things. The exact behavior may vary depending on the funding source and the country due to different implementations and local regulations. The exact time at which an unused authorization "clears" from the customer's funding source and is no longer visible on their statement can also vary, and might take 10 days to no longer show up in some cases.
The rest of the PayPal authorization valid period -- a "post-honor" period, for lack of a better term -- begins on about day 4 and lasts until the end of day 29. During this time a capture attempt can still be made, and will succeed if money is available from the funding instrument. Such a later capture is roughly equivalent to the buyer themselves attempting a new transaction that is of type immediate capture, in the sense that they will succeed or fail for the same reasons.
Reauthorizations to get a new 3 day honor period (but which do NOT restart the 29-day authorization valid period) are almost always pointless. From day 4 to 29 just do a capture when you are ready, and forget you ever heard of the concept of reauthorization.

Google Measurement Protocol offline apps and event dates

I want to use Google Measurement Protocol to record offline events, i.e. take data from an EPOS system and track them in Google Analytics. This would be a batch process once a day. How do I tell Google what the date of the event is? If the console app went offline for a few days I wouldn't want three days worth of events to be associated with one day.
Your best best currently is to use the Queue Time Measurement Protocol Parameter.
v=1&tid=UA-123456-1&cid=5555&t=pageview&dp=%2FpageA&qt=343
Queue Time is used to collect offline / latent hits. The value represents the time delta (in milliseconds) between when the hit being reported occurred and the time the hit was sent. The value must be greater than or equal to 0. Values greater than four hours may lead to hits not being processed.

Scheduling Logic for Calendar Events That Repeat on a Monthly Basis

I'm currently developing a internal application for a company that does patient transport between hospitals and doctor's offices. The module that I'm working on now will give the company the ability to track their various vehicle maintenance expenses and services performed as well as give them the ability to schedule different maintenance services for each vehicle in their fleet.
Different types of maintenance are performed at different time intervals. These are to be repeating events. Some are to be repeated weekly, some monthly, and others every three months.
For the maintenance events that repeat on a monthly or semi-monthly basis I'm a little unsure how I should go about determining days in future months that a event should be scheduled if the date is late in the month and that particular day does not exist a in a subsequent month.
For example, if I schedule a event on January 31st that is to be repeated monthly then I'm unsure where in February that event should be assigned. I would appreciate any suggestions from anyone who has developed a scheduling application detailing how you accounted for these types of scheduling problems.
Looks like I jumped the gun asking this question. I decided to see how Google Calendar handles monthly recurring events. If I add a event for January 31st 2012 and set it as a recurring event then I am given the option to have that event repeat every month that has day 31 or to repeat the last Tuesday of each month.
In my case it would be best to have the event repeat the last Tuesday of each month because the vehicle maintenance shop is closed on Sundays and the maintenance cannot skip a month just because that particular day did not exist in each month.