What are some architecture patterns to consider when building a REST api sync application?

TLDR;

We're syncing data by calling a third party api, mapping the data and posting to a destination api. We are integrating more third parties down the line. What are some architectural patterns to consider for this kind of software?

---

The Details

I'm on a team that builds a solution that sync data from one REST Api to another. We're currently only syncing from one source, to one destination. More sources will be implemented.

We started building an Onion Architecture solution, and it works just fine. However:

• Since we only want to sync (put or post) new data, we have to call the destination api first to see what we already have. This happens in the infrastructure layer of the application.
• Then we call the source api, and filter it so we only have new or updated data (also in infrastructure layer)
• The data is converted from third party objects to core objects (also in infrastructure layer)
• Then it's converted to the destination objects, and sendt to the destination api (also in infrastructure layer)

_{You might see where this is going..}

Most data processing happens in infrastructure layer, because the core layer is independent of everything (projects, nugets, etc.). If we were to follow the Onion pattern completely, we would process in Core, but that means that we have to do more mapping before comparing data.

We all feel that a lot of what exists in the core layer, are unnecessary, since we basically just map to core objects and then map straight to the infrastructure objects.

Do you have any suggestions to other architectures we should concider?