What's the API's max call frequency limit for client updates?

[vitaprimo]

The host that used to update my tunnel client's address doesn't exist anymore so while setting the cron job on another host and before I knew it I got distracted trying to do it in systemd, cron yet changed again in Fedora Server.

I ran the curl command a few times to see the output, to see if the output could be useful to do something else with it, e.g; directly updating nameservers, which made me forgot this is an API and that it must have a call limit and by the third command in a minute or so I got an "abuse" reply. It's a bit scary; I don't want to be banned or anything.

I sent three updates within a minute or so, before this; it was scheduled every five minutes on macOS' launchd.

So... two consecutive [successful] updates I sent could be the [near] last and [near] first of their respective <consecutive-call-timeout-period> but the third merely seconds after makes me think at least a minute must be passed before another update. I don't know; I'm speculating since I couldn't find information about it in the site.

Could you tell me what the allowed frequency please? (or share a link with the info)

Thanks!

[kcochran]

As long as you're only updating when your IP changes, you'll never hit the limits.  As noted in the API information, it conforms to the Dyn dynamic DNS API, whose return codes are documented at https://help.dyn.com/remote-access-api/return-codes/

You should only send updates when your IP changes.  Any well-behaved script should store your IP from the previous run, and only hit the API when there's a change.

We're reasonably strict on this, as there are a surprisingly large number of people who send updates every minute (or few seconds!) when there's no actual change to their IP address.  Virtual all of the rate-limit blocks time out in a reasonable period of time, on the order of minutes.  People who are on the level of updating every few seconds are a different story, however.