Skip to main content
Hexagraph caches responses across all requests to reduce latency on frequently accessed entities and search queries. When a record has been recently fetched, subsequent requests for the same data are served from cache rather than retrieved from upstream sources — returning results significantly faster without consuming additional upstream resources.

​
How Caching Works

When you request an entity or search result that has been recently queried — by you or any other API user — Hexagraph serves the response from cache rather than fetching it from OpenAlex or Crossref. This process is completely transparent: cached and uncached responses have exactly the same structure and fields. You don’t need to do anything special to benefit from it. The cache is keyed by request parameters, so the same entity ID, filter combination, or search query will hit the cache on repeated calls within the cache window.

​
Cache Benefits

  • Lower latency for popular entities. Heavily requested records — widely cited papers, prominent authors, major journals — are likely already warm in the cache, meaning your request returns near-instantly.
  • Reduced likelihood of hitting rate limits on repeated lookups. Serving from cache is still counted against your rate limit, but the speed improvement makes it easier to paginate or batch through results within a given time window.
  • More consistent response times. Cache hits eliminate variability introduced by upstream API response times, giving your integration more predictable performance.

​
Cache Freshness

Cached data reflects the most recently fetched version of a record from OpenAlex or Crossref. Because academic metadata — publication details, citation counts, author affiliations — changes infrequently, cache freshness is generally not a concern for typical use cases. Newly published works or recently updated author records will be fetched fresh on first access and then cached for subsequent requests.

​
Working with Caching

Keep these patterns in mind to get the most out of Hexagraph’s caching layer:
  • Repeated lookups for the same entity ID benefit most. If your application fetches the same output or author across multiple sessions or users, the cache ensures fast delivery after the first request warms it.
  • GraphQL multi-entity queries populate the cache for each entity. When a single GraphQL request resolves several entities, each individual entity response is cached — so subsequent lookups for any of those entities will be served from cache.
  • Journal and source data is specifically optimized for caching. Source-level metadata (journal names, ISSNs, publisher links) tends to be stable and is cached aggressively, making it ideal for use cases that repeatedly reference the same publication venues.
The cache is shared across all API users. This means a popular entity queried by another user may already be in cache when you request it — giving you fast response times even on your very first lookup of that record.