Attio is rate limiting this app
Attio asks the app to slow down from time to time. What an agent sees depends entirely on whether the card already had something worth reading.
Neither presentation means anything is misconfigured, and neither is remembered: the next view of the request tries again rather than sitting on a stale refusal.
#The two presentations
Situation | What the card does | Retry offered |
|---|---|---|
Rows from a successful lookup are already on screen | Keeps them and adds a quiet grey line: "Attio is rate limiting this app, so these values may be out of date." | No. The reader already has something to read, and a retry would spend the budget again. |
There is nothing to show | Becomes the whole card: "Attio is rate limiting this app. Try again in a minute." | Yes, a "Try again" control sits under it. |
#What the app does before it gives up
When Attio asks for a pause, the call is retried exactly once, after the delay Attio itself asked for, and that wait is capped at ten seconds. A second refusal ends the render and the card says it will pick the customer up again shortly rather than pretending the data is missing. One busy minute cannot turn into a loop.
The wording is fixed, and always names Attio. The rate-limit sentences are written on the card rather than chosen per failure, so they name Attio whatever it was that slowed the app down. Seeing them is not proof that Attio was the limiter.
#A slow answer is a different message
Being slow and being unreachable are reported differently, because the fix is different. A call to Attio is abandoned after twelve seconds and the card says Attio did not answer within twelve seconds; when Attio cannot be reached at all the sentence is "Capable could not reach Attio." The connection test on the settings screen uses a shorter eight-second budget, because somebody is watching a spinner while it runs.
#Anything else is the error state
Any other failure shows a sentence written for a reader plus a "Try again" control. When no sentence was supplied it reads "This customer card could not be loaded.", and when the request itself failed in the browser it reads "The customer card could not be loaded. Try again in a moment." No failure takes the card down, so a problem never hides the parts that did work.
#Why the card is cached at all
A resolved record is kept warm for fifteen minutes and shared by everyone in the project looking at requests from that customer, so a second agent's view costs no call at all. That is what keeps the number of calls down, and it is why a rate limit is uncommon enough to be worth investigating rather than shrugging at.
#A few things worth knowing
A rate limit with values on screen offers no retry button on purpose. The absence of a button is not a bug.
Nothing degraded is ever remembered: failures, rate limits and unconfirmed permissions are used once and discarded, so reopening a request is a genuine second attempt.
The settings screens allow Attio eight seconds against the card's twelve, so a slow spell can fail a connection test on a project whose card is still answering.
#Related
Back off, wait a minute, try again. That is the whole remedy.
