Does an API with a rate limit need to provide requests remaining? I'm writing code to make requests from a public API. They give me an API key, and the API provides 1000 requests per day for free, and a max of 60 per minute. In the event that I pass one of those limits, I will be liable for a fee. I don't have to enter my payment details to use the API. This all seems fine. However, there is no count of how many requests I've used on a given day on the website or on my account page, nor in the API's response (in the response header or data). So, given a line of code that calls the API, there is no way for me to know whether running it will cost me money. When I ask the company, they say it's up to me to add a counter and keep track. So unless all my applications/environments tell each other how many requests I've used, then I have no means of tracking how many I have remaining. In addition, I don't know what time the count resets each day, or each minute. So even if I keep track and only have one application that uses the API, there's no way for me to know if my count equals their count because I don't know when they reset it. The only thing they'll tell me is when I owe them money by going over the limit. Is this okay, or is there some legal expectation that they tell me when a request will cost me money, such as returning a count of requests remaining this day/minute? The company's headquarters is in the UK, but the API is used worldwide. Edit: After some further looking at the company's website and documentation, and comparing to what it used to say using Archive.org, I've determined that it will probably not incur charges if I reach a limit, but further requests will instead return HTTP 429 (the code for &quot;rate limit exceeded&quot;), which seems much more reasonable.
You could establish your own server which calls the API and maintains a counter, and have al your applications call that server, the server call the API, and the server can also return a count to the application, or even return a failure code if the count is too high. As for when the count turns over, a few days experiment should establish that, but given that the API is based in the EU, I would guess it turns over at midnight UTC (aka Greenwich mean time), but of course that is only a guess. Has the API management declined even to tell when the count rolls over? That seems odd. As to the legal obligations of the API management, it would be good practice for them to have the API return a count, but I don't see that they can be required to do that. I don't know of (and could not find) any law which mandates such a count. I do think that they should inform you of the time of day at which they roll the count over. I have not yet found a law which specifically requires this.
This is a matter of state law, and so could in theory vary from state to state. But I think that in most, if not all, US states, a public utility like a water or electric company must take any customer unless they have a history of unpaid bills or the like. They don't have to lay new pipes or run new wires to bring service to you if it is at a location not previously served, however. In the Maryland code, § 7-307 ( Termination of service to low income customers) provides: (1) Subject to paragraph (2) of this subsection, the Commission shall adopt regulations concerning the prohibition against or limitation of authority of a public service company to terminate service for gas or electricity to a low income residential customer during the heating season for nonpayment. (2) In adopting the regulations required under paragraph (1) of this subsection, the Commission shall consider and may include provisions relating to: (i) the circumstances under which service may and may not be limited or terminated; (ii) the minimum heating levels required to maintain life, health, and safety; (iii) the medical, age, disabling, or other individual characteristics that are relevant to a prohibition against or limitation on the termination of service; (and other provisions) That the Public Service Commission is empowered, and indeed obliged, to issue binding regulations on when service may be terminated might imply a duty to provide service in the first place, but that is not as clear as I would like. I know that in practice a utility runs a credit check and may demand a deposit if the results are not satisfactory, but I do not see a law compelling that behavior. It may be in regulations adopted by the commission.
client must provide me a suite in his hotel that costs $10K for a night based on a contract we held in the past (the contract has expired as of 31-Dec-18 but he never rendered the service because I didn't ask for it. The contract mentioning $10K has expired and is no longer relevant. You had a chance for a $10K suite before 31 Dec 2018 but you did not take it. There is no obligation on the client to keep this chance for you indefinitely. What happens now ($6K suite) is a completely new contract you have accepted. You are not entitled to anything in relation to the $10K suite from the past opportunity.
There are two &quot;cancellations&quot; here. There is a contract between the customer and the company. This contract was ended. Also, as part of GDPR obligations, the data of the former customer was removed. Now the &quot;credit&quot; part suggests a pre-paid phone, which are often described as &quot;no contract&quot;. Legally this is incorrect. There is a contractual obligation for the phone company to deliver phone services (typically expressed in minutes of call time, # of text messages and/or MB of data). Now the pre-paid contract with high likelihood had a clause which dealt with inactive accounts. For instance, the minutes of call time may expire after 5 years. A &quot;credit&quot; that has not been converted to minutes, messages, or megabytes may also expire. When this happened, the company might need to keep the customer data on their records for two more years (for legal reasons), so the 7 year period does not sound weird at all. As soon as the legal reason to retain the data has ended, the GDPR indeed states that the data should be removed. That act is not connected to the credit expiring years before.
If you have an agreement with a company that specifies &quot;you agree to give me something of value, in case I give you something of value&quot;, you have a contract. In order for there to be a contract, there has to be actual acceptance of the offer. You can put out on a web page some contract stating those terms, and if you get positive acceptance of the contract (hence the standard click-through technology), then as long as you have done the thing promised, you can bill them for doing the thing promised. It's not clear what thing of value you are offering on the web page, since it's not &quot;doing actual work&quot;. Them sending you an email isn't you doing something. One thing you could do is block all incoming emails, and for money you agree to unblock emails from registered subscribers. Just announcing that you will bill anyone for emailing you does not create a contract, because the emailer need not have even seen your announcement. This is why e-contracts need a click-through button. It's legal to request money, but there is no legal obligation for them to comply. That will be $10, please.
Obtaining consent for cookies is not required by the GDPR at all. Instead it is covered by the e-privacy directive, which as a directive rather than a regulation, must be implements by specific legislation in each individual country. The exact requirements vary with the law of each country. An e-privacy regulation has been proposed, which would have scope similar to the GDPR, would replace the Directive, and would not require national implementing legislation. However it has not yet been adopted. Proposed versions have significantly different requirements than the current Directive. Nor does the GDPR require consent for advertising that does not involve the processing of personal information, unlike some other privacy laws such as the California CCPA. However, if the Google package sets cookies without consent that are not strictly necessary for operation of the web site, it might well fail compliance with some of those national laws implementing e-privacy. Also, even necessary cookies must be disclosed to the user, as I understand it, possibly only in general terms. Several national Data Protection agencies have said that cookie compliance is not a major priority, at least not until an e-privacy regulation is in place. But that does not mean that lack of compliance is legal. Unfortunately I see no way for a developer using the Google package to correct this issue within the package. One would either have to implement a different solution, or trust that Google will fix this before enforcement becomes a serious issue. However, the app developer could add a separate general cookie consent banner, and turn off all adds if consent is not given, I believe.
You are processing the users IP address in order to carry out the translation to a physical location (see my comment for the technical issues with that) and an IP address is most certainly considered personal information, so yes under the GDPR you are going to need a published policy because you are both data controller and data processor. You need to inform the user of what you are doing, and you need to tell them of the legal basis for the processing (there are several under the GDPR, of which consent is only one - but in your case its going to be the easiest to justify). If you use a third party service for the location translation, you also need to inform the user of that and make available the third party services data processing policy.
Do I need to inform the user about storing the score locally? No, there is no need as long as you don't transmit, store or process any personal info. It's doubtful that the score could be considered personal info, but you're not sending it to your servers in any way, so you don't seem to be processing it anyway. Do I need consent for using non-personal AdMob? You have to check this with AdMob, but usually, if it is non-personal, they shouldn't be processing any PI, so you're clear without informing. Do I need to ask for the age? How should I handle kids? Again, you're not processing any PI, so regarding GDPR there isn't any problem. Can I disallow a user from using the app if consent is not given? If you needed consent, no, it would be unlawful to block a user for not giving consent, unless it is impossible to provide the service without it. See recital 43: Consent is presumed not to be freely given if [...] the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.