When writing code to interact with a third party like a SaaS provider, you typically need to write both code to handle the API the third party uses, and translate their data model into your data model. One thing I've found that makes this easier is to do each step separately: First write a library to interact with their API using their own data model, then separately write code to translate between your data model and theirs.
The concepts I discuss in this post include things like the Single Responsibility Principle, but I worry that using buzzwords will make it unclear why I recommend this, so I'll discuss why you should do this in plain language instead of referring to other concepts.
So why bother?
It's easier to do one thing at a time
Writing code to interact with an API is tedious but not complicated. Writing code to translate between another data model and your internal data model is complicated, because you need to understand both data models and figure out a way to align them.
By writing your library code using the third party's data model, you can do one thing at a time, which allows you to put all of your focus on it. I find that banging out tedious code and then thinking about complicated code is faster than trying to do both at the same time.
This can also let you split work between people at different levels (have someone more junior or an AI write API code, then someone more senior figure out the data model translations).)
Closing the black box
Code that deals with your own data model is likely to change as your data model evolves over time, but third party API's are likely to be relatively stable. Writing a library using the third party's API allows you to look into their API once, write the code, then never look at it again. Once you're done, it's a black box and it doesn't need to be changed, except to handle new features or for major version updates.
Easier debugging
When debugging issues with your library, it's helpful to have the variable and function names in your code match up exactly to the documentation. This lets you read the documentation while debugging without needing to translate.
Open sourcing
This is a minor benefit, but if your library code doesn't depend on the internals of your codebase, you can open source it. Open sourcing can help with hiring (some engineers really like opportunities to work on open source code) and in some cases you can get external contributors (although this is much harder than you might think).