App Attest — are there rate limits or quotas on generateKey / attestKey

Question

Created 3w

Replies 1

Boosts 0

Participants 2

I am seeing recurring DCError.invalidKey in my iOS app using App Attest, and I'am trying to determine whether throttling or a quota can be a contributing factor before we look further.

Questions

Are there rate limits or quotas on generateKey, attestKey, or generateAssertion — scoped per device, per key, or per app? I understand exact thresholds may not be published; what I'd mainly like to know is whether such limits exist and roughly what timing window they apply over.
If a limit is hit, which error surfaces? Specifically, can throttling ever present as DCError.invalidKey, or would it always be serverUnavailable (or another distinct code)?
Does calling the attestation flow repeatedly in a short window (e.g. several times within a few minutes from an onboarding sequence) risk triggering throttling or anti-abuse rejection?
Am I right that generateAssertion is entirely on-device and therefore not subject to any server-side limit — i.e. only attestKey contacts Apple's servers?
Is throttling one of the documented causes of invalidKey, or is invalidKey strictly a key-state error (key absent from the Secure Enclave, already attested, from a prior install, etc.)? Being able to rule throttling in or out would help us narrow the investigation considerably.

Thanks.

Answer 1

Engineer OP

Apple

1d

Are there rate limits or quotas on generateKey, attestKey, or generateAssertion — scoped per device, per key, or per app?

There are no rate limits for generateKey: or generateAssertion:, as those API operations occur locally on the device.

For attestKey:, we recommend developers stay below 100 requests per second.

If a limit is hit, which error surfaces? Specifically, can throttling ever present as DCError.invalidKey, or would it always be serverUnavailable (or another distinct code)?

It will typically be DCError.serverUnavailable. In some rare cases, if the server returns a 4xx/3xx it may map to DCError.invalidKey. If you have more information, please file a feedback assistant and we can investigate more with logs.

Does calling the attestation flow repeatedly in a short window (e.g. several times within a few minutes from an onboarding sequence) risk triggering throttling or anti-abuse rejection?

It will risk rate limiting. You should attempt some back-off before immediately retrying.

Am I right that generateAssertion is entirely on-device and therefore not subject to any server-side limit — i.e. only attestKey contacts Apple's servers?

Yes.

Is throttling one of the documented causes of invalidKey, or is invalidKey strictly a key-state error (key absent from the Secure Enclave, already attested, from a prior install, etc.)?

It is not, it does seem to be thrown in some cases from network failures (unrelated to rate limiting). Noting your feedback, we will investigate improving the error codes to better indicate actionable steps for the developer.