Response Code in Automation

A response code is a three-digit number that an API or server sends back after your automation makes a request. It tells you whether the request succeeded, failed, or needs something different.

Response codes are how automation knows what to do next. Without checking them, your workflow might silently move forward after a failure as if nothing went wrong.

Key Takeaways

• Three-digit status signal: Every API response includes a code that tells you whether the request worked or what went wrong.
• Grouped by category: Codes starting with 2 mean success, 4 mean a client error, and 5 mean a server error.
• Essential for error handling: Your automation can check response codes to decide whether to retry, alert, or stop.
• Often visible in logs: Most automation platforms show the response code for every API step in the run history.
• Not just for failures: 2xx codes confirm success and often include data your workflow needs for the next step.

What Do the Different Response Code Categories Mean?

Response codes fall into five categories. 1xx is informational, 2xx means success, 3xx is a redirect, 4xx means the client made an error, and 5xx means the server had an error. In automation, 2xx and 4xx are the ones you encounter most.

You do not need to memorize all codes, but you should know what each category means at a glance.

• 2xx Success: The request was received, understood, and processed correctly. Your automation can proceed.
• 3xx Redirect: The resource has moved. Most HTTP clients follow redirects automatically without your automation needing to handle them.
• 4xx Client Error: Something about your request was wrong. Check the URL, authentication, or request body for errors.
• 5xx Server Error: The server had an internal problem. This is not your automation's fault, but you may need to retry the request.

Knowing which category a code falls into tells you where to look when debugging a failed step.

What Are the Most Important Response Codes to Know?

The codes you will encounter most in automation are 200, 201, 400, 401, 403, 404, 422, 429, and 500. Each one tells you something specific about what happened with your request.

Learning these nine codes covers the vast majority of situations you will face when building automation.

• 200 OK: The request succeeded and the response body contains the result. This is the standard success response for GET, PUT, and PATCH requests.
• 201 Created: A new resource was created successfully. This is the standard success response for POST requests.
• 400 Bad Request: The request body has a formatting error or is missing required fields. Fix the request structure and try again.
• 401 Unauthorized: Authentication is missing or invalid. Check your API key, OAuth token, or other credentials.
• 403 Forbidden: The credentials are valid but the account does not have permission for this action. Check the access level granted.
• 404 Not Found: The resource you are trying to access does not exist. Check the record ID or URL path for errors.
• 422 Unprocessable Entity: The request format is correct but the data values fail validation. Check for invalid email formats, missing enums, or constraint violations.
• 429 Too Many Requests: You have exceeded the API's rate limit. Add delays or reduce the frequency of requests.
• 500 Internal Server Error: The server had an unexpected problem. This is the API provider's issue. Wait and retry.

MDN's complete HTTP status code reference is the most comprehensive resource for looking up any code you encounter.

How Should Your Automation Handle Different Response Codes?

Your automation should check response codes after every API call and take a specific action based on the result. Successful codes allow the workflow to continue. Error codes should trigger retries, alerts, or fallback steps depending on the error type.

Ignoring response codes is one of the most common automation design mistakes.

• On 2xx: Continue the workflow and use the response body data in the next step as expected.
• On 4xx: Log the error, alert your team, and stop or redirect the workflow. These errors will not resolve themselves without a fix.
• On 5xx: Retry the request after a short delay. Server errors are often temporary and resolve on retry.
• On 429: Wait for the rate limit window to reset, then retry. Some platforms handle this automatically with built-in backoff logic.

At LOW/CODE Agency, we add response code checks to every API step in workflows we build, with specific handling for each error category.

How Do You See Response Codes in Your Automation Platform?

Most automation platforms show response codes in the step output or run history. After a step runs, check the raw response data to find the status code and the full response body returned by the API.

You do not need external tools to see response codes when building automations in visual platforms.

• Step output viewer: After a test run, click on the API step to see its output, including the status code and response body.
• Run history logs: Every automation run has a log that shows each step's output. Look for a status or code field in the API step results.
• Error messages: When a step fails, most platforms surface the response code and error message directly in the failure notification.
• HTTP module in Make or n8n: These platforms expose the full HTTP response including headers and status code as step output values.

Why Do Some Successful Requests Return Different 2xx Codes?

Different 2xx codes communicate specific types of success. 200 OK means the request was processed and data was returned. 201 Created means a new resource was successfully created. 204 No Content means success but no data is returned in the body.

Knowing these distinctions helps you configure the correct success check for each API step.

• 200 OK: Standard success for GET requests and for PUT or PATCH updates that return the updated record.
• 201 Created: Standard success for POST requests that create a new resource. The response body usually contains the new record.
• 202 Accepted: The request was received and will be processed asynchronously. The result is not immediately available.
• 204 No Content: Success with no response body. Common for DELETE operations and some PUT responses where no data is returned.

What Is the Difference Between a 401 and a 403 Response?

A 401 means the request has no valid credentials or the credentials are expired. A 403 means the credentials are valid but the account does not have permission to take that action. Both prevent access but for different reasons.

This distinction matters because the fix is different for each one.

• 401 fix: Reauthenticate, refresh the OAuth token, or update the API key. The problem is credential validity.
• 403 fix: Check the account's permissions or role settings in the connected app. The problem is access level, not credentials.
• Both block the request: Neither returns a response body with the data you requested. Both require intervention before the automation can succeed.
• Check both during setup: Test API connections before going live to confirm the credentials work and the account has the correct permissions.

Conclusion

Response codes are the language that APIs use to communicate with your automation. Learning to read them turns confusing failures into clear diagnoses. Build your workflows to check response codes, handle errors explicitly, and your automation will be far more reliable and easier to maintain.

Want Automation That Handles API Errors Correctly?

Checking response codes and responding to them appropriately is the difference between automation that works once and automation that works reliably for months.

At LOW/CODE Agency, we build API integrations with proper response code handling, retry logic, and error alerting at every step. We have delivered 450+ projects for clients including Medtronic, American Express, and Coca-Cola.

• Response code handling: Every API step we build checks the response code and takes the appropriate action for success, client errors, and server errors.
• Retry logic for 5xx: Server errors trigger automatic retries with exponential backoff so temporary failures do not break your workflow.
• Rate limit management: We configure request pacing to stay within API limits and handle 429 responses before they cause downstream failures.
• Error alerting: Every automation we build sends immediate notifications when an unexpected response code occurs so nothing fails silently.
• Full testing coverage: We test every API step against success and failure scenarios before going live, including edge cases that most teams skip.

If your API automations are failing silently or hard to debug, let's fix them at lowcode.agency.