Run your API in test mode to confirm it processes records the way you expect before you deploy it to production. A test run lets you review the behavior of each step — transformation, mapping, filter, or hook — and adjust your configuration to handle every variation of result or response those steps might return. After deployment, use debug logging to capture full detail for live requests.
Before you run a test, complete these steps:
- Configure your API request.
- Configure your API response.
- Configure your lookups and imports.
- Provide mock API request data for your request and for any lookup step you want to test.
- Provide mock response data for each import.
Your test run logs include the headers, query parameters, and path parameters from your mock data. As with test mode in flow builder, you can review test run results and execution logs for each step and hook.
Run test is unavailable until your API meets all of these conditions:
- The HTTP method and relative URI are configured in the API request.
- The API request has mock data. APIs that use the
GETmethod don't need it. - The HTTP status code is configured in the API response.
To run a test, select Run test in either of these places:
- The API builder toolbar
- The Run console panel
The Run console, the first tab under the API canvas, shows each step's status and errors as your API runs, even before the run finishes.
Note
The Run console reflects the status of the most recent run or the run currently in progress. Error counts don't change when you start resolving errors.
Test run error messages and codes tell you what went wrong and where. Review them to fix issues before you deploy your API.
You can review test run logs for every step of your API, including the request and responses, branches, lookups, and imports. A blue T on a step means a test run log is available for it.
To view your test run errors:
- Select Run test
to run a test.
-
When the test finishes, review the Run console to see where errors occurred.
-
Select the error indicator or the blue T on the step to open the Test run errors window. If a step shows only the blue T, open the step, then select View debug logs.
-
Review the message, code, and source for each error, then select an error to see its details.
Review schema validation failures
A test run reports schema failures only when Enable request/response validation is on. When it's on, schema failures appear as errors:
- A request failure shows an error indicator on the API request node.
- A response failure shows an error indicator on the response node that ran, including the success response node.
Select the error indicator to open the errors drawer. Configure is hidden on the node while the error indicator shows. On the response node, select View debug logs to see the HTTP 500 status and the generic message the caller receives. If API builder can't check a schema, the test returns HTTP 501 and names the schema location.
Schema failures count toward the error count. For how validation works, see Validate API requests and responses in API builder.
While a test runs, Run test changes to Cancel test run. Select Cancel test run to stop the test.
If a test run takes longer than 100 seconds, a message appears. You can cancel the run or wait for it to finish.
To protect system performance, a test run is canceled automatically when:
- The API runs longer than two minutes.
- An uncaught exception occurs.
Test run data is deleted automatically when:
- Your Celigo platform session expires.
- You run the next test in the same session.
- You leave API builder.
- You change the URL.
Keep these tips in mind when you use test mode:
-
Add mock response data to each destination step before your first test. Otherwise, the first run uses dummy data and the results aren't accurate. Add mock response data in either of these ways:
- Select Populate with live data in the destination's mock response panel. Running the import can create or update records.
- Enter your own data from the application's API documentation. The data must include
statusCode.
- Test results don't change until the next test run, even if you change the API configuration.
- Test results are cleared, not saved, when you leave your API, refresh, run a new test, or enable your API.
Debug mode temporarily raises your API's logging to the Debug level for every request it receives while active. It captures request and response payloads, headers, and the inputs and outputs of internal steps such as mappings and transformations. It overrides whatever log level is otherwise set for as long as it's on.
Debug mode is separate from the test run functionality described in Run a test. Test runs validate your API configuration against mock data before deployment. Debug mode captures live execution detail for real inbound requests once your API is running.
Note
Debug logging requires payload consent to be enabled at the account level by an admin or owner. If payload consent isn't enabled, a prompt asks you to request admin approval when you try to enable debug mode. You can resend the request once every 24 hours.
To enable debug mode:
- In API builder, select Enable debug mode in the toolbar.
- In the Capture debug logs for next panel, enter a duration in hours and minutes.
- Select Start.
Debug mode takes effect immediately, and every request received during the active window is logged at the Debug level. To view the captured logs in the Request history tab, see View API request and execution logs in API builder.
The minimum duration is 5 minutes. The maximum debug duration depends on your subscription:
| Subscription | Maximum debug duration |
|---|---|
| Free trial | 15 minutes |
| Standard | 1 hour |
| Professional | 24 hours |
| Enterprise | 72 hours |