226 - IM Used
HTTP 226 IM Used is a success status code indicating that the server has fulfilled a GET request by returning a "delta" (a set of changes) rather than the full resource. It requires the client to apply these instance manipulations to a previously cached base version.
Last reviewed: March 14, 2026|Editorial standard: source-backed technical guidance
What Does IM Used Mean?
A 226 status represents "Efficiency via Diffs." Instead of re-sending a 10MB file when only 1KB has changed, the server sends a 226 response containing only the delta (Instance Manipulation). The client must have a valid base version (tracked by ETags) and the correct algorithm (e.g., vcdiff) to reconstruct the final resource. If the client or any proxy in between doesn't support this specialized handshake, the operation fails or falls back to a standard 200 OK.
Common Causes
- -Specialized Data Sync: High-frequency data synchronization where only small increments of large datasets change.
- -Unsupported Delta Algorithm: The server sends a delta using an algorithm (like
gdiff) that the client library cannot process. - -Proxy Interference: Intermediate proxies or CDNs stripping the
A-IM(Accept-Instance-Manipulation) header, forcing the server to return 200 OK instead of 226. - -Cache Mismatch: The client's cached base version has an ETag that doesn't match the reference version used by the server to compute the delta.
How to Fix IM Used
- 1Implement Fallback: If you receive 226 but can't process deltas, retry the request without the
A-IMheader to get the full resource (200 OK). - 2Sync ETags: Ensure your client correctly sends
If-None-MatchorIf-Matchso the server knows exactly which base version you have. - 3Proxy Configuration: If using Nginx or HAProxy, ensure it is configured to forward
A-IMandIMheaders without modification. - 4Clear Cache: If reconstructed data appears corrupted, wipe the local base version and perform a fresh "full" GET request.
Step-by-Step Diagnosis for IM Used
- 1Confirm the presence of the
IM(Instance Manipulation) header in the 226 response to identify the algorithm used. - 2Verify the
A-IMheader was sent in the request; without it, a server should never return 226. - 3Compare the reconstructed file size with the expected full resource size.
- 4Check if the client library (e.g., Axios/Fetch) is throwing an "Unknown Status Code" error, as 226 is not in many default success lists.
Delta Handshake Logic (RFC 3229)
- -The Request: Client sends
GETwithA-IM: vcdiffandIf-None-Match: "v1". - -The Response: Server sees only small changes, returns
226 IM UsedwithIM: vcdiffand the binary diff. - -The Reconstruction: Client applies the diff to "v1" to get "v2".
Decision Matrix: 226 vs. 200 vs. 304
- -200 OK: Full resource returned (No bandwidth saving).
- -304 Not Modified: Zero data returned (Resource is identical).
- -226 IM Used: Only changes returned (Maximum efficiency for modified resources).
Implementation Examples
curl -v -H "A-IM: vcdiff" -H 'If-None-Match: "v42"' \
https://api.errorreference.com/v1/sync-data
# Expected 226:
# < HTTP/1.1 226 IM Used
# < IM: vcdiff
# < ETag: "v43"
# (Binary delta follows)const fetchData = async (url, etag) => {
const res = await fetch(url, { headers: { 'A-IM': 'vcdiff', 'If-None-Match': etag } });
if (res.status === 226) {
// Check if we have the tools to apply delta
if (!canApplyDelta('vcdiff')) {
return fetch(url); // Fallback to full 200 OK
}
// Apply delta logic...
}
return res.json();
};How to Verify the Fix
- -Successfully reconstruct the full resource from the 226 delta and verify its hash against a standard 200 OK response.
- -Confirm that removing the
A-IMheader from the request causes the server to return 200 OK with the full body. - -Ensure no intermediate proxy is caching the 226 delta as if it were a full 200 OK response.
How to Prevent Recurrence
- -Modern Alternatives: For new systems, prefer JSON Patch (RFC 6902) or GraphQL Subscriptions over 226 delta encoding, as they have better library support.
- -Header Transparency: Include
A-IMandIMin your "Allowed Headers" list for all WAF and CDN configurations. - -Documentation: Clearly mark endpoints that support 226, as most developers will mistake it for a server error if undocumented.
- -Pro-tip: 226 is extremely rare in 2026 because Brotli/Gzip and HTTP/2/3 header compression provide similar efficiency with much less architectural complexity.
Decision Support
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.