With one Receiver and multiple Senders, Push method of the integration with API on Receiver side is more preferable in general compare to  Pull method when APIs are developed on Senders side. Here are listed a reasons supporting this statement from the most critical to the least one:

• From the economical point of view, development of one API on Receiver side takes less resources than the development of APIs on multiple Senders side.
• API on Receiver side allows to eliminate security risks related to unauthorized access to Sender data, since the Sender is only initiator of the data transmission and always knows where the Sender sends the data. This is compare to risks of unauthorized access to the data when API is developed on Sender side, since Sender doesn’t “know” the Receiver.
• Support of the multiple APIs on Sender side takes more resources and more error-prone than the support of one API on Receiver side when changes in API have to be implemented in parallel for all Senders.
• Senders always know the status of the data transmission, since the Receiver replies with the status after successful data receival.
• API on Receiver sider supports Push method in accordance with Service-oriented Architecture​ (SOA) when services are provided to the other components by application components.
• Additional Architecture items to consider related to Push method that expects API on Receiver side:
  • Data Interaction frequency​ – Push method is used when there is a need for real-time interaction​
  • Data Processing​ – Push method is used when data is processed in Receiver side​
  • Scheduled update with different intervals​ – Push method is used when data is processed at equal intervals with defined schedule​
  • High volume of data​ – Push method is used for comparatively low volume bulk data.​
  • Complex data sources – Push method is used when data is not integrated from many sources providing complex cross system integration​
  • Data identification​ – Push method is used when data identification needs to happen on Sender side.​

Possible Risks

Receiver can use proprietary solution without out-of-the-box API. In this case, Receiver has to develop API in-house.

References:

1. https://blogs.sap.com/2013/12/09/to-push-or-pull-that-is-the-question/​ – To Push or Pull? That is the question.