Skip to main content
Version: 2025.003.000 (beta)

FAQs

Which authentication method should I use?

To start working with our APIs, you need to use Session Tokens. We have created a more extensive guide on selecting the authentication method to help you choose the one you will use when you go into production.

How can I download the swagger files in .yaml format?

To download the files in .yaml format, you can simply click on the reference link in swagger, e.g., https://apicsdemo.teamsystem.io/swagger/v1_IntegrationInfrastructure/swagger.json and rename the extension to https://apicsdemo.teamsystem.io/swagger/v1_IntegrationInfrastructure/swagger.yaml.

Where can I find my Company_ID?

The Company_Id is a very important parameter for TSE in Cloud WebAPIs because it allows the user to use methods with a company scope. To retrieve the companyID, go to the following link.


What to do in case of warning error messages?

To force and ignore a warning during the execution of a service, you need to add the 'force' parameter in the call. The 'force' parameter requires the list of warning codes that you want to ignore (e.g., force=97788,97760) or a single warning code.

To identify the list of warning codes, you need to call the service without the aforementioned parameter.

If, during the insertion of a record via POST, the response includes "warningCode": 97788, you need to add the parameter "&force=97788".

Can I schedule my tasks in the cloud?

Yes, it is possible!
Starting from version 2025001000, you can schedule your tasks in TSE Cloud.
Simply follow the same procedure used in the on-premises version.

info

NOT ALL TASKS SCHEDULABLE ON-PREM ARE SCHEDULABLE IN THE CLOUD
The scheduling procedure has been modified to allow scheduling only processes compatible with the Cloud environment.

Configured schedules, which on-premises are managed by the operating system scheduler, are part of the standard scheduling processes in the Cloud and are visible on the landing page of scheduled processes.
Two new services have been made available to support scheduling in the Cloud:

  • A web service that executes the sets present in the schedule. You can find an example here. This service allows you to "force" the execution of a schedule or move the execution to your client, delegating the scheduling part to it.
  • A set of services for downloading and uploading files in the Cloud, which can optionally be included in the scheduled actions. Some examples are available here.
warning

Temporary folders
Data exchange occurs in a temporary directory in the Cloud, which should not be considered reliable for file storage, as it is subject to automatic timed removal.

These services allow you to replicate file-based scheduling methods on local folders in a simple and immediate way.
For demonstration purposes, a PowerShell example is provided, enabling file exchange to and from the Cloud without writing code.
The PowerShell file can be scheduled as a replacement for the .bat file automatically generated on Windows on-premises services. Cloud scheduling will then be able to process the files to import or export the required data.

Is it possible to exclude the Multiple Agents stored on the customer?

Using the callOptions property with the parameter EsclusioneAgentiMultipli, it is possible to include or exclude the customer's multiple agents.

If the parameter EsclusioneAgentiMultipli=true, the system will only consider the agents provided in DocumentoTestataAgentiMG, ignoring those suggested by the customer configuration. For more details, see the example.

How to generate a PDF print?

To enable PDF printing of a document, you can retrieve the streamPDF of a document with a GET request using the Print command. This streamPDF will be decoded and converted to PDF using any conversion program.

For more details, go to the following example.

Can I develop my integration on-premises without having to change the code when transitioning to the cloud?

Certainly! Even in an on-premises environment, you can use token-based authentication. Perform the authentication call by specifying "password" as the grant_type instead of "token" and enter the password you use for on-premises calls. This way, you can use the session token to simulate the same calls that in a cloud environment would require the token.

It is possible to create a sales document without indicating the warehouse article code by specifying the client article code?

Certainly! Simply include the entity codartcli in the body of the POST request instead of codartMg66, as shown below:

{
    "righe": [
    { 
        "progrRiga": 1.0,
        "codartcli": "ARTCLI124500",
        "qta1": 1.000
    }
}
Is it possible to transition from a NULL CurrentState to a POPULATED CurrentState using PUT or PATCH?

NO. The PUT or PATCH call does not allow setting the initial state of a flow. Considering a specific entity, to transition from a NULL CurrentState to the DefaultState, it is necessary to use the StateManagementService and the action 'setstate'.

With the PUT or PATCH call, it is possible to transition from one state to another, but the initial state of the Flow must be set. Additionally, the transition must be coherent and consecutive, taking into account the Available States and the progression according to the predefined Flow.

For example, considering a document that is in the CurrentState = 'idState': 40 (as indicated in the JSON below), it can transition to the next state 'idState': 41, which is the consecutive state provided by the flow, but it cannot transition to CurrentState 43.


{
    "statoAttuale": {
        "statoCorrente": {
            "idStato": 40,
            "seq": -1,
            "indTipoStato": 0,
            "extensionData": [],
            "additionalData": {}
        },
        "statiDisponibili": [
            {
                "idStato": 40,
                "seq": 1,
                "indTipoStato": 0,
                "extensionData": [],
                "additionalData": {}
            },
            {
                "idStato": 41,
                "seq": 2,
                "indTipoStato": 0,
                "extensionData": [],
                "additionalData": {}
            },
            {
                "idStato": 42,
                "seq": 3,
                "indTipoStato": 0,
                "extensionData": [],
                "additionalData": {}
            },
            {
                "idStato": 43,
                "seq": 4,
                "indTipoStato": 0,
                "extensionData": [],
                "additionalData": {}
            },
            {
                "idStato": 44,
                "seq": 5,
                "indTipoStato": 0,
                "extensionData": [],
                "additionalData": {}
            }
        ],
    },
}
How can I populate the CodSede field (DO11_CODSEDE_CG31) present in the DocumentoTestataMGDTO DTO?

The office code must be defined within the officeCO field for the TestataDocumento and in the corresponding officeCO field for the relevant RigaDocumento. If the office code of the row differs from that of the header, it must be specified in the body of the request. For example, you can specify code 1 for the "Additional Office" in the TestataDocumento and code 2 for the "Pesaro Office" in the RigaDocumento, as shown below:

For the TestataDocumento:

{
  "officeCO": {
    "cap": "47900",
    "citta": "Rimini",
    "codice": 1.0,
    "dittaCg18": 1000.0,
    "idmediaCg99": null,
    "indDimcentrocomm": 0.0,
    "indIrizzo": "Additional Office",
    "numerorea": null,
    "progRea": null,
    "prov": "RN",
    "rowversion": "AAAAAAAc51s="
  }
}

For the RigaDocumento:

{
  "officeCO": {
    "cap": "",
    "citta": "Pesaro",
    "codice": 2.0,
    "dittaCg18": 1000.0,
    "idmediaCg99": null,
    "indDimcentrocomm": 1.0,
    "indIrizzo": "Pesaro Office",
    "numerorea": null,
    "progRea": null,
    "prov": "RN",
    "rowversion": "AAAAAAAcT+U=",
    "extensionData": [],
    "additionalData": {}
  }
}