The service path is basically a URL that takes you to a sort of “dashboard” for a service. You can use this dashboard to test a service, to see our XML request/response structure, to see what operations are available to you, and a slough of other useful information. Listed below are the most useful ones.

View all available operations for a Web service We’ll use Address Validation US as an example. Let’s go to its service path: “Address Validation US“.

To run a transaction, you’ll need to use your existing Address Validation trial or production key, or get one here. Without a key, you won’t be able to run a test, but you’ll still be able to see operations and their respective inputs and outputs, etc. (Please note: Trial and production keys are product specific. To run a test on another product, you will need to secure a key for that product. Please click here for a complete selection.)

Run a quick transaction against an operation Once at the service path, click on an operation, place values in the textboxes, and click “Invoke”. The service will return a response in raw XML format. This is what your application sees before it parses out the data.

View all expected inputs for an operation Click on an operation and note the input fields on the form that appears.

For example, “ValidateAddressWithDPV” expects Address, Address2, City, State, PostalCode, and LicenseKey as input fields. All of these fields must be sent to our service (even if they are sent without any data) for it to accept the request. View all possible outputs for an operation Scroll down past the form and look at the SOAP section. The 2nd shaded box will show you the list of XML outputs that our service returns on a successful transaction. For example, <BarcodeDigits> and <CountyName> are both possible outputs for ValidateAddressWithDPV. Determine how to format a request for SOAP, HTTP POST, or HTTP GET Beneath the operation input form, you will see SOAP followed by a shaded box containing the format the request should be in for a SOAP request. Beneath that you will see HTTP GET, and finally HTTP POST. Both have a shaded box showing the expected input format for that protocol. Keep in mind that most programming languages will handle these request schemas for you. But when troubleshooting, it’s sometimes necessary to view the request made by the application and compare to the expected request. See what the output will look like Go to the operation page, and either run a transaction (which will output the raw XML in a browser window), or scroll down to the protocol you will be using (SOAP, HTTP POST, or HTTP GET) and view the 2nd shaded box underneath the header. This will show you how the XML will be returned to you. View the WSDL Go to the main service path URL for your specific DOTS Web Service and click “Service Description”. For example, go here and click on “Service Description” (located in the first line above the operations). The Web Services Definition Language, or WSDL (pronounced Whizz-dull) describes all these operations, inputs, operation descriptors, data types, etc. In fact, all the service path pages you see were generated from the WSDL. If you use a language that requires a WSDL URL, then it likely is generating entire objects from that document and handling all the request and response structures for you. So there you have it! I hope you get to add this to your utility belt too. It’s an invaluable tool that I use on a daily basis.