Inbound Web Service TroubleshootingIssue This article describes web service issues and possible solutions. Symptoms Web services are not workingNo response when invoking web service requestTime out on web service requestEmpty response when making web service requestResolutionEnable debugging properties Enable these properties and verify logs to see if the instance received the request. This also provides some information if the request cannot be parsed. SOAP debug property : glide.processor.debug.SOAPProcessorREST debug property : glide.rest.debug As of the Fuji release, there is no debugging property for JSONv2. Check various logs provided on the instance, such as Transaction logs, All logs (under System Log), or localhost log files using the log file browser, to see if the instance received the request. Status codes from web services response. The response might have a status code other than 200 success. This could provide some information about what happened to the request. Typical Error codes: 400: Bad request, unparseable, non-existing endpoint, invalid headers401: UnAuthenticated (Request does not provide proper credentials.)403: Forbidden (Caller is not authorized to perform the operation.)500: Internal server error (An error on the server. Check logs to see if you can find more information or exception stack trace.) ACLs failures If you observe something working when using admin credentials, but not with a specific user, the problem is often with ACLs. There are different ACLs defined to secure the information. Processor level ACLs: These are ACLs that are enforced at the processor level - only certain users can access certain processors. SOAP Webservice Endpoints: Requires at least one SOAP role (soap, soap_query, soap_create, etc.)REST endpoints: Requires rest_service role Table and Record level ACLs: There are provisions to define ACLs on tables and records. This is something admins usually create to restrict the visibility of data to certain users. Web services honor those ACLs. If you don't receive a response or receive an empty response, it might be that you have access to the endpoint, but not to the particular data you are trying to access. Next steps If you turn on debugging and don't see any requests being logged, it indicates the following: The request is not making it out of your network Verify the proxy firewall settings of your network. Work with your network team to see if the request is making it out of your network. Check the IP information of your instance.The connection is failing with handshake failure. This indicates that you need a certificate from the ServiceNow instance to be installed on your client-side. The request reached the instance and is blocked by semaphores lock. Look at the /stats.do page to see the semaphores available. If you see there are no semaphores available and every request is failing with timeout, you may have a large set of requests lined up because of some integration to a particular web service using all available semaphores. Try to stop the integration and see if semaphores become available. Work with your integration team to send short bursts of requests instead.