The codes, one by one
200 OK
The most common HTTP response on the internet. When you load any normal webpage, call an API, download a file, if things go right, you get 200.
It means that the request was understood, here’s what you asked for.
This page is loaded with 200. Google’s homepage sends 200. Wikipedia sends 200. It’s the default “everything’s working” signal. One thing worth knowing, 200 is also the fallback. If a server is not sure which 200 code fits in, it just returns 200.
HTTP Cloud status Code 200:
HttpRequest req = new HttpRequest();
req.setEndpoint('https://api.stripe.com/v1/checkout/sessions');
req.setMethod('POST');
// AUTH HEADER
String auth = 'Bearer ' + secretKey;
req.setHeader('Authorization', auth);
req.setHeader('Content-Type', 'application/x-www-form-urlencoded');
System.debug('SECRET KEY USED => ' + secretKey);
// PAYMENT DATA
String successUrl = config.Success_URL__c + '?status=success';
String cancelUrl = config.Cancel_URL__c + '?status=cancel';
String body =
'payment_method_types[]=card' +
'&mode=payment' +
'&success_url=' + EncodingUtil.urlEncode(successUrl, 'UTF-8') +
'&cancel_url=' + EncodingUtil.urlEncode(cancelUrl, 'UTF-8') +
'&line_items[0][price_data][currency]=usd' +
'&line_items[0][price_data][product_data][name]=Debt Payment' +
'&line_items[0][price_data][unit_amount]=5000' + // $50.00
'&line_items[0][quantity]=1';
req.setBody(body);
Http http = new Http();
HttpResponse res = http.send(req);
if(res.getStatusCode() == 200){
Map<String, Object> result =
(Map<String, Object>) JSON.deserializeUntyped(res.getBody());
paymentUrl = (String) result.get('url');
System.debug('Stripe URL: ' + paymentUrl);
}else{
errorMessage = 'Stripe Error: ' + res.getBody();
}
}catch(Exception e){
errorMessage = 'Payment Error: ' + e.getMessage();
}
201 Created
Same as 200 in that the request worked, however 201 specially manners something new is made at the server.
For example signing up for an account. You fill in your details, hit sign up, and the server creates your account. It replies with 201 because a new factor now exists that didn’t before.
201 responses usually include a Location header pointing to the newly created thing, so you know where to find it. If you’re building APIs, don’t return 200 when you create something. Return 201. It makes a real difference in telling the client what actually happened.
202 Accepted
202 is the honest code. The server is basically saying: I got your request, I’ll deal with it, but I’m not done yet.
Good example, you click “Generate Report” in some dashboard. That report might take 30 seconds to pull together. The server doesn’t want to keep your browser waiting that long, so it returns 202 right away and processes the report in the background. When it’s done, you get a notification or the status updates.
Important: 202 does not mean the job succeeded. It only means it was received and queued. The actual work could still fail later.
203 Non-Authoritative Information
203 is a transparency code. The request worked, but the response came from a middleman, a proxy, a CDN, rather than directly from the original server. And that middleman may have changed something along the way.
You rarely see this in practice. Most proxies just pass along the original 200 without changing the status. But 203 exists for situations where the middleman wants to be upfront about what happened.
204 No Content
204 is a quiet success. The server did exactly what you asked, there’s just nothing to send back. Think about deleting a file. You hit delete, it’s gone. What should the server return? There’s no file anymore. So it sends 204, it worked, there’s simply nothing to say.
You also see this with autosave. Google Docs saves in the background constantly. Each save fires off a request, gets a 204 back, and the page doesn’t change at all. That’s exactly the point, it worked without interrupting you.
205 Reset Content
Similar to 204 in that nothing comes back in the response, but 205 also tells the browser to reset the current view, usually by clearing a form.
Think of a feedback form where you want users to submit multiple times. After each submission, 205 would clear the text box so they can write again right away. Honestly, 205 is barely used anymore. JavaScript handles form resets on the client side now. But it’s in the spec.
206 Partial Content
This one is genuinely interesting, it’s how video streaming works. When you watch something on YouTube or Netflix, your browser doesn’t download the entire video file upfront. That would be slow and wasteful. Instead, it requests a small chunk using something called a Range request. The server sends just that piece and returns 206.
As you watch, the browser keeps requesting the next chunks. If you skip ahead, it requests the chunk for that timestamp. The whole thing stays smooth without ever downloading the full file.
206 also makes download resuming possible. If your connection drops halfway through a large download, a good download manager saves how many bytes it already got. When you reconnect, it sends a new Range request from exactly that byte. The server sends 206 and picks up right where it left off.
207 Multi-Status
207 is for when one request triggers multiple operations that can each have different outcomes.
It comes from WebDAV, the file management extension of HTTP. Say you ask the server to move ten files in one request. Some move fine, others are locked by another user. 207 bundles all those individual results into one response so you can see exactly what happened to each file.
Some APIs use 207 for batch operations too, send multiple actions at once, get individual results for each.
208 Already Reported
Very niche. This only really applies to WebDAV situations where the same resource shows up in multiple places in a directory structure. When the server is building a 207 response and the same resource appears more than once, it uses 208 for the repeat, basically saying “already mentioned this one.”
You almost certainly won’t run into 208 in regular development.
226 IM Used
226 stands for “Instance Manipulation Used.” The idea: instead of sending you the whole file every time something changes, the server sends only what changed, a diff.
Think of a document where someone made edits. Instead of resending all 50 pages, the server sends only the lines that changed.
In practice, 226 never really caught on. ETags and conditional requests solve the same problem more simply. Interesting concept though.
