/
Families of APIs

Families of APIs

Owned by Janina Mincer-Daszkiewicz
Last updated: 26 Apr 25

Operation of the EWP network is based on the set of APIs. These APIs come in groups related to specific business processes, like handling inter-institutional agreements, learning agreements, nominations, etc. For Business Process Owners it is important that these processes are implemented in full and can be supported by both partners in the mobility.

Between 10/12/2024 and 9/04/2025 providers of the Mobility software discussed how to regulate this grouping of APIs.

The following groups have been recognized:

  1. General Purpose

    1. Institutions API,

    2. Organizational Units API.

  2. File

    1. File API.

  3. IIAs

    1. Inter-institutional Agreements API,

    2. Inter-institutional Agreements CNR API,

    3. Inter-institutional Agreements Approval API,

    4. Inter-institutional Agreements Approval CNR API.

  4. Mobility Factsheet

    1. Mobility Factsheet API.

  5. Outgoing Mobilities LAs

    1. Outgoing Mobility Learning Agreements API,

    2. Outgoing Mobility Learning Agreements CNR API.

  6. Outgoing Mobilities (Nominations)

    1. Outgoing Mobility API,

    2. Outgoing Mobility CNR API.

  7. Incoming Mobilities ToRs

    1. Incoming Mobilities ToR API,

    2. Incoming Mobilities ToR CNR API.

  8. Incoming Mobilities (Nominations)

    1. Incoming Mobilities API,

    2. Incoming Mobilities CNR API.

The following rules have been formulated and must be obeyed:

  1. If API is implemented, all its endpoints MUST be implemented (stats included).

  2. Each HEI must provide Institutions API from the General Purpose group.

  3. Providing Organizational Unit API from the General Purpose group is not mandatory but highly recommended.

  4. If HEI implements any API from the IIAs group it MUST provide all APIs from this group and from the Mobility Factsheet group.

  5. HEI may provide APIs from the Mobility Factsheet group without providing APIs from the IIAs group.

  6. If HEI sends a link to a file in any request, it must provide an API from the File group.

  7. If HEI provides any APIs from the Outgoing Mobilities (Nominations) group or the Incoming Mobilities (Nominations) group, it must provide all APIs from both of these groups and the Mobility Factsheet group. In practice, that means that HEI MUST be ready at the same time to play the role of the Sending partner and the Receiving partner.

  8. If HEI provides any APIs from the Outgoing Mobilities LAs group, it must provide all APIs from this group. In practice, that means that HEI MUST to be ready at the same time to play the role of the Sending partner and the Receiving partner.

  9. If HEI provides any APIs from the Incoming Mobilities ToRs group, it must provide all APIs from this group. In practice,that means that HEI MUST to be ready at the same time to play the role of the Sending partner and the Receiving partner.

It must be remembered that the requirements are formulated in relation to HEI, not a node – one HEI may have several nodes (manifest files).