Skip to main content

Overview

The Pump.fun API supports ETag-based HTTP caching to reduce bandwidth usage and improve application performance. When content hasn’t changed, the API returns a 304 Not Modified response instead of the full data, saving both bandwidth and API rate limits.
Implementing proper caching can significantly reduce your API usage and help you stay within rate limits while providing faster responses to your users.

How ETag Caching Works

ETags (Entity Tags) are unique identifiers assigned to specific versions of resources. The caching workflow follows these steps:
  1. Initial Request: You make a request to an endpoint
  2. Server Response: The API returns data with an ETag header
  3. Store ETag: Your application stores the ETag value
  4. Subsequent Request: Include the ETag in an If-None-Match header
  5. Server Check: The API compares the ETag to the current resource version
  6. Response:
    • If unchanged: 304 Not Modified (no body, use cached data)
    • If changed: 200 OK with new data and updated ETag

ETag Response Header

When you request a cacheable resource, the API includes an ETag header:
string
Unique identifier for the current version of the resource. The W/ prefix indicates a “weak” ETag.

Using If-None-Match

To check if content has changed, include the stored ETag in the If-None-Match header:

Content Unchanged (304)

If the resource hasn’t changed, the API returns:
No response body is included. Use your cached data.

Content Changed (200)

If the resource has changed, the API returns:
Store the new ETag and update your cache.

Implementation Examples

Basic Caching

Advanced Caching with Expiration

Cache Best Practices

When you receive a 304 status code, use your cached data. Never treat 304 as an error.
Different endpoints and parameters have different ETags. Store them separately for each unique URL.
Even with ETags, implement a time-to-live (TTL) for cache entries. Stale data older than your TTL should trigger a full refresh.
Not all endpoints support ETags. Design your cache to gracefully handle responses without ETag headers.
When you POST, PUT, or DELETE resources, invalidate related cache entries to ensure consistency.
Prevent unbounded cache growth by implementing an LRU (Least Recently Used) eviction policy.

Cache Invalidation

Invalidate cache entries when:
  • After write operations: Clear cache after creating, updating, or deleting resources
  • On authentication changes: Clear user-specific cache when logging in/out
  • On explicit refresh: Provide users with a manual refresh option
  • After TTL expiration: Automatically remove stale cache entries

Benefits of Caching

Proper caching implementation provides multiple benefits for your application and API usage.

Reduced Bandwidth

304 responses contain no body data, significantly reducing bandwidth usage especially for large responses.

Lower Rate Limit Usage

Some API implementations don’t count 304 responses against rate limits, allowing more effective requests.

Faster Response Times

Cached data can be returned immediately without waiting for network requests, improving user experience.

Better Reliability

Cached data can serve as fallback when the API is temporarily unavailable.

Monitoring Cache Performance

Track cache effectiveness with metrics:

Common Pitfalls

Avoid these common caching mistakes that can lead to stale data or poor performance.

Don’t Cache User-Specific Data Globally

Always scope cache entries to the authenticated user:

Don’t Ignore Query Parameters

Different query parameters should have separate cache entries:

Don’t Cache Error Responses

Only cache successful responses: