WSDL and endpoint configuration | Product Documentation Documentation

Retrieve the WSDL

For the signing service, retrieve the WSDL from the following address:

CODE

https://<Host Address>/ts/svs.asmx?WSDL

https://<Host Address>/ts/svs.asmx?WSDL

Replace <Host Address> with the host Sovos provided for your environment:

Production: twod.trustweaver.com
UAT: twod-test.trustweaver.com
DEV: twod-dev.trustweaver.com

Important: The WSDL contains two ports: SwitchServiceSoap (SOAP 1.1) and SwitchServiceSoap12 (SOAP 1.2). Only use the SwitchServiceSoap port. The SOAP 1.2 port must never be used.

Service endpoints

The following table summarizes all TrustWeaver service endpoints and how each is obtained.


Service	Port name	MTOM	How to obtain
Signing Service	`SwitchServiceSoap`	Not used	WSDL available at `https://<Host Address>/ts/svs.asmx?WSDL`. Use the `SwitchServiceSoap` port only. Don't use `SwitchServiceSoap12`.
Storage Service	`StorageServicePort`	Used	Endpoint address provided during onboarding.
Storage Service (legacy)	`StorageServiceLegacyPort`	Not used	Use only if your Web Services stack doesn't support MTOM. Endpoint address provided during onboarding.
Admin Service	`AdminServicePort`	Not used	Endpoint address provided during onboarding.
Notification Service	`NotificationServicePort`	Not used	Endpoint address provided during onboarding.

Cache the WSDL locally

Sovos recommends caching the WSDL locally rather than downloading it at runtime. Some Web Services stacks download the WSDL each time to confirm it matches the client stub. Because TrustWeaver communicates any changes in advance, runtime downloads are unnecessary, reduce performance, and require the WSDL to be accessible in production, which is undesirable.

Most Web Services stacks provide a local caching mechanism that can be enabled in configuration. Enable this before moving to production.

SOAP messages

TrustWeaver uses document/literal SOAP encoding. Requests and responses are wrapped in a SOAP 1.1 envelope. For error handling details, see Error handling and status codes.

Namespace prefixes

The following XML namespace prefixes are used throughout this documentation in parameter type columns and code examples. Where a prefix appears in a type name (for example, tac:OmittableDateTime), it identifies the service namespace that owns that type.


Prefix	Namespace URI	Description
tac	`http://www.trustweaver.com/trustarchive/common/v1`	TrustWeaver Archive common types shared across all Compliant e-Invoicing services. Includes `TransactionId`, `AsyncState`, omittable types, and base request/result types.
tas	`http://www.trustweaver.com/trustarchive/storage/v1`	TrustWeaver Archive Storage Service types and operations.
taa	`http://www.trustweaver.com/trustarchive/admin/v1`	TrustWeaver Archive Admin Service types and operations.
tns	`http://www.trustweaver.com/trustarchive/notification/v1`	TrustWeaver Archive Notification Service types and operations. Declared as the default namespace (`xmlns=`) in Notification Service request examples.
(default)	`http://www.trustweaver.com/tsswitch`	TrustWeaver Signing Service. Used as the default namespace (`xmlns=`) in all Signing Service request and response examples; Example: `<SignRequest xmlns="http://www.trustweaver.com/tsswitch">`. No prefix is assigned.
xs	`http://www.w3.org/2001/XMLSchema`	W3C XML Schema built-in datatypes, such as `xs:string`, `xs:int`, and `xs:dateTime`.
xsi	`http://www.w3.org/2001/XMLSchema-instance`	XML Schema instance namespace. Used in some request examples for `xsi:nil` and `xsi:type` attributes.
soap	`http://schemas.xmlsoap.org/soap/envelope/`	SOAP 1.1 envelope namespace. Used in all SOAP request and fault envelope examples.
ds	`http://www.w3.org/2000/09/xmldsig#`	W3C XML Digital Signature namespace. Appears in signed document structures and signature validation output.
xades	`http://uri.etsi.org/01903/v1.3.2#`	ETSI XML Advanced Electronic Signatures (XAdES) namespace. Appears in XAdES signature structures returned by the signing service.

Note: In code examples throughout this documentation, namespace prefix declarations are omitted from child elements for brevity. A full declaration such as xmlns:tac="http://www.trustweaver.com/trustarchive/common/v1" appears only on the root element of each example.

Omittable types

Some TrustWeaver API parameters use omittable wrapper types instead of plain primitive types. An omittable parameter carries a different meaning depending on whether the element is present in the request:

Element omitted: The value is excluded from the request. For update operations, this typically means "leave the existing value unchanged." For optional parameters, it means the parameter is not provided.
Element included: The element must contain a Value child element with the actual value. An included omittable element with no Value child is invalid.

This pattern exists because primitive types on some platforms (such as xs:boolean and xs:int on .NET) cannot be null. Wrapping the value in an element lets a client explicitly signal that the parameter was omitted, which would otherwise be lost during deserialization.

The following omittable types appear in TrustWeaver API parameter tables:


Type	Wraps	Example
tac:OmittableBoolean	`xs:boolean`	CODE <MyParam> <tac:Value>true</tac:Value> </MyParam> `<MyParam> <tac:Value>true</tac:Value> </MyParam>`
tac:OmittableInt	`xs:int`	CODE <MyParam> <tac:Value>42</tac:Value> </MyParam> `<MyParam> <tac:Value>42</tac:Value> </MyParam>`
tac:OmittableDateTime	`xs:dateTime`	CODE <MyParam> <tac:Value>2030-01-01T00:00:00Z</tac:Value> </MyParam> `<MyParam> <tac:Value>2030-01-01T00:00:00Z</tac:Value> </MyParam>`

Compliant e-Invoicing operation parameters

TrustWeaver Compliant e-invoicing uses wrapped parameter style. All input and output messages are wrapped in an element. The input wrapper element has the same name as the operation, and the output wrapper has the operation name with Response appended. For example, the StoreInvoice operation uses StoreInvoice as the input wrapper and StoreInvoiceResponse as the output wrapper.

Binary data encoding

Compliant e-Invoicing uses Message Transmission Optimization Mechanism (MTOM) for efficient encoding of binary data. Using MTOM can significantly improve performance when accessing the storage service. The admin service messages are small and don't benefit from MTOM encoding.