The REST API Explorer lets you test your Scripted REST APIs and built-in ServiceNow endpoints without leaving the instance. You'll be able to send requests, inspect responses, and verify behavior using your current user context.
Why the REST API Explorer exists
Before the REST API Explorer, testing REST endpoints meant switching between ServiceNow and external tools like Postman, copying authentication tokens, and dealing with CORS issues. Developers would write an API, then jump to another application to test it, losing context and wasting time. The people building and maintaining these APIs — platform developers and admins — need to test quickly during development and troubleshoot issues without authentication headaches.
How the Explorer works
The REST API Explorer is built into ServiceNow and automatically uses your current browser session for authentication. You select a namespace (like your custom Scripted REST API namespace or built-in endpoints), pick an API and resource, then configure parameters and send requests. The key insight: responses reflect your user's ACL permissions, so you're testing exactly what your user context can access. This makes it perfect for development testing but means you need to test with different user accounts to verify role-based behavior.
Beyond basic testing
Once you're comfortable with the Explorer, use it for more sophisticated scenarios: test error conditions by sending malformed data, verify ACL behavior by switching user accounts in different browser sessions, and document API behavior by capturing request/response examples. Advanced users integrate Explorer testing into their development workflow by keeping the Explorer open in a second tab while coding, allowing rapid iteration without breaking context.
Before you start
- •rest_service_admin role or admin role
- •At least one Scripted REST API or access to built-in ServiceNow APIs
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to the REST API Explorer
Go to System Web Services > REST API Explorer. The interface loads with a default namespace selected — usually 'now' for built-in ServiceNow APIs. The Explorer automatically authenticates using your current browser session, so you don't need to configure credentials.
Bookmark this page if you test APIs regularly — it's buried in the menu structure.
Select your target namespace and API
Click the Namespace dropdown and choose your Scripted REST API namespace (it matches the namespace you defined in your API). If testing built-in APIs, leave 'now' selected. The API Version dropdown populates based on your namespace selection — pick the version you want to test.
Custom Scripted REST API namespaces appear at the bottom of the dropdown list.
Choose the API resource and method
The API dropdown shows all available APIs in your selected namespace. Choose your target API, then select the specific resource from the Resource dropdown. Finally, pick the HTTP method (GET, POST, PUT, DELETE) that matches what you want to test. The interface updates to show relevant parameter fields based on your selections.
Configure request parameters
Fill in any path parameters that appear as form fields — these replace variables in your REST resource path like {sys_id}. For query parameters, use the 'Request Parameters' section to add name-value pairs. If your API expects a request body (POST/PUT), enter JSON in the Request Body field. The Explorer validates JSON syntax as you type.
Path parameters are required and clearly labeled — query parameters and request body are optional depending on your API design.
Review authentication and headers
The Authentication section shows 'Use browser session' by default — this is what you want for testing during development. The Explorer automatically includes necessary headers like Content-Type. Add custom headers in the Request Headers section if your API requires them, but most Scripted REST APIs don't need additional headers for basic testing.
Send the request and analyze results
Click Send to execute your request. The Response section shows the HTTP status code, response headers, and response body. Pay attention to the status code first — 200 means success, 403 suggests ACL issues, 404 means the endpoint wasn't found. The response body contains your API's actual data or error messages.
Use the Response Headers to debug caching issues and check custom headers your API sets.
Test error conditions and edge cases
Modify your request to test failure scenarios: remove required parameters, send invalid data types, or use malformed JSON in the request body. This validates your API's error handling and helps you document expected behavior. Test with empty strings, special characters, and boundary values to ensure your API handles edge cases properly.
Best practices
Remember that Explorer responses reflect your current user's ACL permissions — test with different user accounts in separate browser sessions to verify role-based access control.
Always test error conditions alongside happy path scenarios — send malformed JSON, missing required parameters, and invalid data types to validate your API's error handling.
Use the Explorer during development but don't rely on it exclusively — external tools like Postman test authentication flows and cross-origin requests that the Explorer can't simulate.
Keep request examples from successful Explorer tests for documentation — copy the request parameters and response body to help other developers understand your API contract.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue