--- schema_version: "1" id: a97c3a4ef265b873083b2e3f15cd6f8e9ecf04a42b7f6c7ebdf300b15aa9ffe8 title: Step 4. Test the API collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/api-led-test.md canonical_url: https://docs.mulesoft.com/general/api-led-test source_site: docs.mulesoft.com content_type: documentation content_hash: 2a4bc3a7dbf56b40566dc73c8becb11fce7ed63f10ee4613236bfd8a95c40350 description: MuleSoft Documentation Site latest: true --- --- product: Getting Started keywords: api testing, apikit validation, mulesoft api, logging, api-led connectivity, run api, test api --- # Step 4. Test the API > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Test your API locally before deploying it to the cloud. You run the API in Anypoint Code Builder, send requests using Postman, add logging to track requests, and use the built-in debugger to inspect the Mule message at each step. ## Step 4.1: Run and Test Your API 1. Open the Run and Debug panel. Show me how - Click ![](/mulesoft/current/en-us/general/_images/icon-run-debug.png) (**Run and Debug**) in the activity bar. - Use the keyboard shortcuts: - Mac: Cmd+Shift+d - Windows: Ctrl+Shift+d - In the desktop IDE, select **View** > **Run**. 2. Run the Mule app. ![The Run and Debug panel and the button to run the Mule app](/mulesoft/current/en-us/general/_images/api-tutorial-run-mule-app-acb.png)
1Click to open the Run and Debug panel.
2Click the button to run the Mule app.
The Output panel shows startup progress. Wait for `Application started successfully`. 1. Open Postman and send a GET request: ```text http://localhost:8081/api/greeting?name=World ``` 2. Verify you receive: ```json { "message": "Hello, World!" } ``` Your API works! Now let’s add logging and explore debugging. 3. Click ![](/mulesoft/current/en-us/general/_images/icon-stop.png) (**Stop**) in the debug toolbar. ## Step 4.2: Add Logging Logging helps you see what’s happening inside your flows. 1. Click the **Logger** component and configure it: - **Message**: Click **fx** to switch to expression mode, then enter: ```dataweave #["Received greeting request for name: " ++ (attributes.queryParams.name default "not provided")] ``` This message logs the `name` query parameter value or "not provided" if it’s missing. - **Level**: INFO ![Logger component configuration panel showing Message field set to payload and Level field set to INFO](/mulesoft/current/en-us/general/_images/api-tutorial-logger-component-configured-acb.png) 2. Save your changes. ## Step 4.3: Test with Logging 1. Start your application by clicking ![](/mulesoft/current/en-us/general/_images/icon-start-debug.png) (**Run**) in the debug toolbar. 2. Open the Terminal panel to see your application logs: - Mac: `Cmd+\` or select **View** > **Terminal** - Windows: `Ctrl+\` or select **View** > **Terminal** > [!NOTE] Logger output appears in the Terminal panel, not the Output panel. The Terminal > shows the live Mule runtime log as requests are processed. 3. Send a request with Postman: ```text http://localhost:8081/api/greeting?name=World ``` ![Postman UI with the request URL entered](/mulesoft/current/en-us/general/_images/api-tutorial-send-postman-request.png) 4. In the Terminal panel, you’ll see a log entry similar to: ```text INFO [hello-world-impl].get:\greeting Received greeting request for name: World ``` 5. Send a few more requests and watch the logs update. 6. Click ![](/mulesoft/current/en-us/general/_images/icon-stop.png) (**Stop**) when done. ## Step 4.4: Understanding APIKit Validation APIKit automatically validates incoming requests against your API specification. Since your API spec defines the `name` query parameter as required, APIKit: - Validates that the `name` parameter is present before routing to your implementation flow - Returns a `400 Bad Request` error automatically if the parameter is missing - Ensures your flow only executes with valid requests that match the API contract Try it: 1. Start the application. 2. In Postman, send a request without the name parameter: ```text http://localhost:8081/api/greeting ``` 3. Observe that APIKit returns an error response before your flow executes. 4. Check the Terminal — you won’t see your Logger message because APIKit blocked the invalid request. This automatic validation is one of the key benefits of using APIKit — you don’t need to write manual validation code for contract requirements defined in your API specification. ## Step 4.5: Use Breakpoints for Debugging Breakpoints pause execution so you can inspect the Mule message at a specific point in your flow. 1. In the canvas, select the context menu for the **Logger** component, and then select **Add Breakpoint**. ![The context menu for the Logger component with an arrow pointing to the Add Breakpoint option](/mulesoft/current/en-us/general/_images/api-tutorial-logger-context-menu-acb.png) A red dot appears, which represents a breakpoint. ![The Logger component with a red dot representing a breakpoint](/mulesoft/current/en-us/general/_images/api-tutorial-logger-breakpoint-acb.png) 2. Click ![](/mulesoft/current/en-us/general/_images/icon-run-debug.png) (**Run and Debug**) in the activity bar to open the Run and Debug panel. 3. Select **Debug Mule Application** to start your application in debug mode. ![The Debug Mule Application option selected in the Run and Debug panel](/mulesoft/current/en-us/general/_images/api-tutorial-debug-option-acb.png) 4. Send a request from Postman: ```text http://localhost:8081/api/greeting?name=World ``` 5. Return to Anypoint Code Builder. Execution pauses at the breakpoint. The debug toolbar appears at the top of the editor, and the **Variables** panel appears in the Run and Debug panel. > [!NOTE] The Variables panel is in the **Run and Debug sidebar**, not at the bottom of the IDE. > If you don’t see it, make sure the Run and Debug panel is open > (![](/mulesoft/current/en-us/general/_images/icon-run-debug.png) icon in the activity bar). 6. In the **Variables** panel, expand **Mule Message** to inspect: - **payload**: The current message content - **attributes**: HTTP request details, including headers, query parameters, and URI - **vars**: Any flow variables set during execution ![The Variables panel in the Run and Debug panel](/mulesoft/current/en-us/general/_images/api-tutorial-debug-panel-variables-acb.png) 7. Click **Continue** in the debug toolbar to resume execution and complete the request. 8. Click ![](/mulesoft/current/en-us/general/_images/icon-stop.png) (**Stop**) when done. ## What You Learned You ran the API locally and tested it with Postman, then configured a **Logger** to record each request. You learned how APIKit automatically validates requests against your API specification, and used Anypoint Code Builder’s debugger, including breakpoints and the Variables panel, to pause execution and inspect the Mule message at each step. ## Developer Deep Dive Explore advanced testing capabilities: - [Automated Testing with MUnit](https://docs.mulesoft.com/anypoint-code-builder/int-test-munit) - [Advanced Error Handling](https://docs.mulesoft.com/mule-runtime/latest/mule-error-concept) - [Troubleshooting AI Features in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/troubleshoot-generative-ai) - [DataWeave Testing Framework](https://docs.mulesoft.com/dataweave/latest/dataweave-testing-framework) ## What’s Next With your APIs fully tested locally, you’ll deploy them to CloudHub 2.0 to make them accessible to other applications and users. [Step 3. Develop the API](https://docs.mulesoft.com/general/api-led-develop) [Step 5. Deploy the API to CloudHub 2.0](https://docs.mulesoft.com/general/api-led-deploy)