In case you are using a 3rd party mobility management software, chances are that they are currently connecting their software to the Erasmus Without Paper Network to provide you with the functionality to send and receive mobility data via their software. Please get in touch with your respective mobility management software providers to learn more about their involvement in Erasmus Without Paper. 

Overview of the current 3rd party mobility software providers that were part of the EWP projects and initiated the connection with the Erasmus Without Paper Network:

Other 3rd-party software providers who have signed the EWP collaboration agreement and who are developing the EWP-APIs for their clients:

  • AEC
  • Be Smart
  • Cantieri Informatici Srl (Italy)
  • Digitalis
  • ErasmusPort (Turkey)
  • KION (Turkey)
  • Masaryk University
  • Osiris
  • Solenovo
  • Terradota
  • XWS

If you use a 3rd party provider that is not mentioned in the overview above, please let us know or pass on our contact info to your software provider. Each third party provider is responsible for its own software and EWP implementation, so we can only act as an intermediary. 



State of play of the EWP APIs

The first quarter of 2021 has seen significant work on the EWP APIs, which was carried out under the aegis of the EDSSI project. During the second half of 2021 EWP APIs stayed rather stable. Software developers were busy with implementation to keep deadlines imposed by the European Comission for IIAs and LAs. However, some changes are planned for the first quarter of 2022. Small corrections will be made in IIAs and LAs, more substantial changes can be expected in Factsheet API and OMobilities API (related to the nomination procedure). Also the structure of the network will change which might impact your provider.

In May 2021 flowcharts describing mobility processes have been upgraded to fully cover changes in specifications. In June 2021 use cases and scenarios for LAs and IIAs have been posted in GitHub.

The info below summarises the current state of play and planned developments. It is important to share this information with your IT-team/technical provider so they can plan their developments accordingly. It will be updated every half a year (next update: March 2022).

Inter-institutional agreement

Version 5 of the API was published on March 5, 2021 to ensure alignment with the new official template, published on January 29 2021 for the 2021-2027 period. Version 6 was published on March 15, 2021 to incorporate a request from the EWP community to allow changes in contacts without the need to resign the agreement. Small technical update has been done on March 29, 2021; the latest version is 6.0.1 which is backward compatible with 6.0.0.

To support the whole process, the IIA Approval API version 1 should be supported as well.

In first quarter of 2022 we plan to make mobilities per year element in IIA API required to align specification with the final version of the IIA template. EQF element will remain optional as it is optional in the template (some developers wanted to have it mandatory).

All versions of the IIA API previous to 6.0.1 and 6.0.0 are deprecated and will soon be announced as discontinued.

Learning agreements

The learning agreement API was updated on March 10, 2021 to ensure compliance with the official template published on February 9th 2021 for the 2021-2027 period. Small backward compatible update was done on March 26, 2021. The latest stable version is 1.0.1.

No further updates of this API are envisaged for the coming 6 months; all versions previous to 1.0.0 are discontinued.

Nomination 

An updated specification of the nominations API (the so called Outgoing mobilities API) is provisionally scheduled for the first quarter of 2022. ESI will become mandatory, to match it with the required ESI in LA.

Transcripts of records

An updated specification of the API for Transcript of Records (Incoming TOR APIs) is provisionally scheduled for the first quarter of 2022. It will differ in one additional comment saying that in the EWP context ESI (coming from ELMO describing details of ToR) is required.

Manifest files

Substantial technical upgrade is planned for the structure of the manifest files. The main reason for that is to give HEIs full control over their presence in the EWP Network. This is a first step towards the deployment of the Registration Portal which is under development. After the change each manifest file will cover only one HEI. This change is technical, will influence implementations supporting nodes with many HEIs. Some changes may be also taken into account by providers of in-house systems, making their implementation simpler. It will not impact any mobility business process. 

There is no content with the specified labels