About the SOAP API

You are here

The SOAP API is our most comprehensive API. It exposes a wide selection of endpoints, but it's not as easy to work with as our JSON based REST API.

The SOAP API is not being actively developed anymore - instead we're focusing our efforts on improving the REST API.

Documentation

You can find a full list of all available SOAP methods here: https://soap.reviso.com/api1/

Connecting to SOAP

Different languages and frameworks will have their own functionality for connecting to a SOAP-based web service. Most of these involve automatically generating client code based on the WSDL, but it is also possible to build the XML envelopes completely by hand.

You must ensure that the ASPNet session cookie is passed along in all requests - some frameworks will do this automatically, but not all.

Connecting using .NET

There are two ways of connecting to the API through .NET:

1. Adding a service reference in Visual Studio

It is possible to add a service reference in Visual Studio directly (through the add service reference in the project menu). The main drawback with this approach is that it will generate a new proxy with every build, and thus slow down your build process.

To instantiate the client use the following line:

EconomicWebServiceSoapClient client = new EconomicWebServiceSoapClient(); ((BasicHttpBinding)client.Endpoint.Binding).AllowCookies = true;

2. Generating a proxy with WSDL

To invoke the WSDL tool use https://soap.reviso.com/api1/?wsdl /protocol:SOAP12 (notice the SOAP12 - WSDL defaults to SOAP11). The WSDL tool is maintained by Microsoft and you can download it from their site.

The tool then generates a single file named EconomicWebService.cs with the proxy code. This file can then be included directly in a project (this can slow down your Visual Studio as it is a rather big file) or built into a dll that can be referenced from your project.

To instantiate the client use the following line:

var client = new EconomicWebService {CookieContainer = new CookieContainer()};

Notice the CookieContainer part, which ensures that your program keeps forwarding the session cookie to the API.

Connecting using Java

To ensure the cookie is passed back to our service use the following code:

EconomicWebService service = new EconomicWebService(apiUrl);
EconomicWebServiceSoap session = service.getEconomicWebServiceSoap();
((BindingProvider)session).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY,true);

Implementing workflows

Before even trying to implement a given functionality through the API, ensure that you know how to do it in Reviso through the web interface. Trying to map your understanding of a workflow or a terminology from another system to Reviso is one thing, but mapping directly to the API before trying it out in Reviso is even harder.

There are two tricks for figuring out which fields map to which API properties (and also which API objects to use):

  • Change the language in your Reviso test agreement to English (from whatever language you are running in). The API terms more or less corresponds to the GUI terms (the API is strictly English).
  • Trial and error in an Reviso test agreement. Often it is easiest to simply test the API by trying out the different methods and checking the result by logging in through the browser.

Most of the functionality from Reviso is available and more or less works in the same way. The most notable exception is Inventory which to a large extend is not available through the API. The only Inventory functionality available is Orders and CurrentInvoice (it is possible to upgrade an Order to a CurrentInvoice) and CurrentSupplierInvoice.

Note that variants do not work through the API, and electronic invoicing is also not available.

Sending of PDFs must be handled by your integration. The API supplies these via the _GetPdf functions.

When a customer enables an integration that requires certain e-conomic modules to be enabled, it is not possible to determine this directly in SOAP. A workaround is to either use the REST API /self endpoint to get a list of enabled modules or via SOAP to simply test using methods and if you receive an authorization error with error code E0300* it means that a required module has not been enabled.

StockAccessError = "E03000";
DimensionAccessError = "E03010";
ProjectAccessError = "E03020";
PaymentsAccessError = "E03030";
ScanningAccessError = "E03040";
SubscriptionAccessError = "E03050";
AccrualsAccessError = "E03060";

Which methods to test against depends on the modules. For the Project module, for instance, it would be feasible to just retrieve all projects.