Data can come from another server: a URL as the data of a tag, a .curl file in _data/, or the {curl} tag for the raw answer. Each of them takes a ttl - the seconds to keep the answer - and within that time the page is served from the copy instead of asking the source again. A dashboard on an external API then costs one call per ttl, not one per visitor.

A .curl file names the URL and the ttl. Here _data/rates.curl reads the rates from a page of this manual standing in for an API:

<curl>
  <url>SELF://manual/?fragments/rates&amp;padInclude</url>
  <ttl>600</ttl>
</curl>

Its name is a tag, like any data file:

<ul>
  {rates}<li>{$code}: {$rate}</li>{/rates}
</ul>

The same with the URL in the template - the ttl is an option of the tag the data is for, {pad data='https://...', ttl=600} - or the answer as it came, with {curl}:

<p>{curl 'SELF://manual/?fragments/rates&padInclude', ttl=600}</p>

When the source fails after the ttl - it is down, or answers with an error - the last good copy is served and the failure is written to the error log, where an event hook on curl hears it too. Only a good answer is kept, and a copy stays a day beyond its ttl for that purpose ($padCurlStale). $padCurlCache chooses where the copies live: 'file', 'apcu', 'redis', 'memcached', or FALSE to fetch every time.