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 a304 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:- Initial Request: You make a request to an endpoint
- Server Response: The API returns data with an
ETagheader - Store ETag: Your application stores the ETag value
- Subsequent Request: Include the ETag in an
If-None-Matchheader - Server Check: The API compares the ETag to the current resource version
- Response:
- If unchanged:
304 Not Modified(no body, use cached data) - If changed:
200 OKwith new data and updated ETag
- If unchanged:
ETag Response Header
When you request a cacheable resource, the API includes anETag 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 theIf-None-Match header:
Content Unchanged (304)
If the resource hasn’t changed, the API returns:Content Changed (200)
If the resource has changed, the API returns:Implementation Examples
Basic Caching
Advanced Caching with Expiration
Cache Best Practices
Always check for 304 responses
Always check for 304 responses
When you receive a 304 status code, use your cached data. Never treat 304 as an error.
Set appropriate TTL
Set appropriate TTL
Even with ETags, implement a time-to-live (TTL) for cache entries. Stale data older than your TTL should trigger a full refresh.
Invalidate cache on mutations
Invalidate cache on mutations
When you POST, PUT, or DELETE resources, invalidate related cache entries to ensure consistency.
Implement cache size limits
Implement cache size limits
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
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:Related Guides
- Rate Limiting - Reduce rate limit usage with caching
- Headers - Learn about If-None-Match and ETag headers
- Error Handling - Handle cache-related responses correctly