Overview

Unipile caches responses for GET method endpoints so that:

• Fewer requests are sent to the provider, which reduces the risk of hitting rate limits
• Responses are faster when the same data is requested again
• Usage stays predictable while keeping data accurate through automatic invalidation

This page describes default behavior, what is cached, how invalidation works, and how cache interacts with rate limits. To control cache on a per-request basis (e.g. no-store, no-cache, max-age) or to check cache status in responses (X-Cache, Age), see the Caching API Reference.

What is cached by default

Unipile caches the responses of all GET method endpoints, except:

• Get a Message Attachment
• Get an Email Attachment

POST, PATCH, and DELETE requests are not cached. They can, however, invalidate related cached GET responses (see Automatic cache invalidation).

Cache duration

• A default TTL of 1 hour is applied to cached GET endpoints. Even if automatic invalidation does not run, data is refreshed at most every hour.
• Cached entries are removed after a maximum of 30 days.

You can override this behavior per request. See the Caching API Reference for details on controlling cache duration and behavior.

Rate limits and cache

When a response is served from cache, the request does not count toward the Rate Limit. Using cache is an effective way to reduce the number of calls that are limited by Unipile and by the provider.

Automatic cache invalidation

Unipile invalidates cached GET responses when newer data is detected, so your integration stays accurate without giving up caching benefits.

1. When a resource is modified via Unipile (POST, PATCH, DELETE)

Any related GET endpoints for that resource have their cache invalidated.

Example:
Calling POST Add a Chat Participant invalidates the cache for GET List all Chat Participants for the same chat.

2. When a resource is updated outside Unipile

If data is created or updated outside Unipile (e.g. via another device or client), the relevant GET listing endpoint is invalidated when Unipile detects the change.

Example:
Receiving or sending a message from another client invalidates the cache for GET List all Chat Messages.

This keeps cached data in sync with the provider while preserving performance.

Advanced cache control

You can control cache behavior per request (skip cache, force refresh, set custom TTL) and check whether responses came from cache. See the Caching API Reference for complete details on:

• Using Cache-Control request headers (no-store, no-cache, max-age)
• Reading cache status from response headers (X-Cache, Age)
• SDK options and code examples

Related topics

• Rate Limits — How Unipile and providers limit requests; cached responses do not count toward limits
• Caching (API Reference) — Request directives and response headers for cache control and status