Docs / Connections & functions
How a call behaves
An http config function is one configured call. What happens when the API does not simply answer is configuration too: the script calls the function by name and gets the answer, or a fault that says what went wrong. This page shows each setting as a short sequence of pictures. The settings themselves are listed in Connections and functions and in the config function reference.
| Setting | What it decides | Without it |
|---|---|---|
retry.times | How often a repeatable answer is asked again | 3 repeats, at most 10 |
retry.status / retry.never | Statuses added to, or removed from, the repeatable set | the platform’s table below |
idempotent | A server error is repeated for any method, and a call cut by a crash is asked again | only safe methods repeat a server error |
pauseOn | Statuses that park the run for the time the API asks | a 429 is repeated in place |
timeoutMs | How long the API may stay silent | 5 minutes, at most 10 |
expect | Which statuses count as an answer; any other is a fault | every status is an answer |
paginate | Where the items and the next page are | one page |
Asked again where that is safe
1The first ask is answered with a status worth asking again: 408, 425, 429, or a 5xx when the method is safe to repeat.
2Each wait doubles from 250 ms, with jitter, and never exceeds 30 s. A Retry-After from the API is honoured within that ceiling.
3At most 3 repeats by default, up to 10 when configured. All asks share one deadline of 60 minutes; no repeat starts past it.
| Answer | Asked again? |
|---|---|
| 408, 425, 429 | yes, for every method |
| a 5xx server error, except 501 and 505 | yes for GET, HEAD, OPTIONS, PUT, DELETE, or with idempotent |
| 400, 401, 404, 422 | never |
| anything else | no — it is the call’s answer |
A long wait parks the run
1Run A's call is answered with a status listed in pauseOn — 429 is the usual one — and a Retry-After.
2The run is saved and parked for the time the API asked. Its slot is free at once, and the next run in the queue takes it.
3When the wait is over the run takes the next free slot, the call is asked again and the script goes on. One wait is at most 24 hours.
Repeating in place holds a slot while it waits. pauseOn gives the slot back:
the run is saved, and it continues when the wait is over. A run that answers a
caller directly cannot be parked; for it a long wait is a fault.
Silence, not total time
1A long download is fine as long as data keeps arriving: every byte restarts the clock.
2No data for longer than timeoutMs ends the call. The default is 5 minutes, the most a function may set is 10.
The circuit protects the API and your queue
15 failures in a row — no connection, or a server error — trip the connection's circuit.
2For 30 seconds every call over that connection is refused at once, without being sent. The error names the connection and when the next try is due.
3Then one call is let through. If it is answered, calls flow again; if not, the circuit stays shut for another round.
The environment’s outbound window
1All calls of one environment share a window of 60 seconds. Up to 3000 calls per window go out as asked.
2The window is full and one more call arrives.
3It is refused at once, with the time the window opens again; nothing reaches the API. The limit is a safety net against a runaway script, not a rate plan: pace a known API limit with pauseOn.
Paging
1The function's paging settings say where the items and the next cursor are. One page is fetched and its rows are stored in a dataset.
2Between pages the run is saved with its cursor and gives its slot back, so a long walk does not hold capacity others are waiting for.
3With pauseOn set, a 429 in the middle of the walk parks the run; it continues at the page it stopped at, never from the start.