How to show validation errors in laravel API while having a form request file separate from controller

# How to Show Validation Errors in Laravel API While Using Separate Form Requests As developers building robust APIs with Laravel, separating business logic, validation rules, and request handling into distinct classes—like using Form Requests—is a cornerstone of clean, maintainable code. However, when dealing with API endpoints, one common hurdle arises: how do we effectively communicate validation errors back to the client when the process fails? This guide addresses the exact scenario you presented: I have a Form Request handling my validations separately from my Controller, and now I need to know how to return those specific validation errors after an API call fails. ## The Power of Laravel's Form Requests When you utilize Laravel's `FormRequest` class for validation, you are leveraging a powerful built-in mechanism. When validation fails within the Request class (e.g., using the `validate()` method), Laravel automatically stops the request execution and prepares an appropriate HTTP response status code for you. For API endpoints, the standard response for failed validation is the **422 Unprocessable Entity** status code. The critical part is understanding that when this error occurs, Laravel automatically serializes the validation errors into a standardized format that can be easily consumed by the API client. ## How Validation Errors Are Handled Automatically The magic happens within the Form Request itself. When you call `$this->validate($request, $rules)`, if any rule fails, the method throws an exception (or handles the failure internally depending on context), and Laravel ensures that the response is structured correctly. For API scenarios, instead of manually catching exceptions in the controller, the recommended pattern is to let Laravel handle the error reporting directly via the Response object. This shifts the responsibility of error formatting from the controller layer to the request layer, keeping your controllers focused purely on business logic execution. ## Implementing Error Handling in the Controller Given that the Form Request handles the initial failure, the Controller’s job becomes simpler: it only needs to handle the successful path (when validation passes) or potentially catch a broader exception if you are implementing custom error handling middleware. In your provided example, where the controller calls `$request->validate(...)` implicitly through dependency injection of the Form Request, if validation fails, Laravel typically stops execution before reaching the main logic. However, if you need to explicitly handle the response for failed requests in an API context, here is how you manage the flow: ```php // my controller use App\Http\Requests\GetOrdersRequest; use Illuminate\Http\JsonResponse; class OrderController extends Controller { /** * Display a listing of the resource. * * @param GetOrdersRequest $request * @return JsonResponse */ public function orders(GetOrdersRequest $request, OrderRepository $orderRepository) { // If execution reaches here, validation in GetOrdersRequest has already passed successfully. $order = $orderRepository->allOrders($request->paginate); return $this->sendSuccess('Orders retrieved successfully', $order); } } ``` **The Key Takeaway:** Notice that if the `GetOrdersRequest` fails validation, Laravel automatically returns a `422` response with the error details. If you are using standard routing and dependency injection as shown above, the controller doesn't need explicit `try-catch` blocks for *validation* errors because they are handled by the framework layer before the method is executed. ## Advanced Scenario: Customizing API Error Responses If you are building a complex API where you want *all* error responses (not just validation failures) to follow a strict, custom JSON structure, you can implement this using Laravel's Exception Handling or custom HTTP Response classes. This aligns perfectly with the principles outlined in documentation like [Laravel Company](https://laravelcompany.com). For API development, ensure your Form Request is correctly configured and that you are utilizing appropriate response helpers (like returning a `Json` response from the controller) to maintain consistency. By trusting Laravel's validation pipeline, you keep your Controller clean and focused purely on data retrieval and business operations. ## Conclusion Separating validation into dedicated Form Request files is a massive win for code organization. When building APIs, the best practice is to let Laravel manage the error reporting flow: 1. **Validation:** Handle all rules within the `FormRequest`. 2. **Failure:** If validation fails, Laravel automatically returns a `422` response with detailed errors. 3. **Success:** If validation passes, the request proceeds cleanly to the Controller, which executes the intended business logic. By following this pattern, you ensure your API is predictable, robust, and adheres to clean architectural separation principles.