I suggest you gentlemen invent a way to put a square peg in a round hole. Rapidly.- Gene Kranz (Apollo 13)
I have been a systems integrator for a quarter of a century. I spend my time staring at one product's square peg and another product's round hole and trying to decide what to do. There is the amazing scene in the movie Apollo 13 where the literally need to put a square CO2 scrubber into a round receptacle. I love the engineer, "we've got a find a way to make this, fit into the hole for this, using nothing but that." That, right there, that has been my career.
This week, sort of out of the blue, I realized that over that my twenty-five year career there has been a philosophy change in how systems integration should work. Protocol technology has marched forward from Remote Method Invocation (RMI) to SOAP to REST with JSON, but there has been a large philosophical difference. In the beginning of days of systems integration, the philosophy was "if I build it, they will come." Everyone believed that inter-operability meant that you needed a robust way for others to access you data. This might be an API to access your data or it might even be having reports available via an SFTP server. In the 2000s, your responsibility as a product company was to make your data available. The company that wanted your data? It was their responsibility to get it.
This was a lucrative time as a systems integrator. I can write a proposal to connect a square peg to a round hole, and write a batch job to make it happen. Maybe it was ETL. Maybe it was Java/SOAP. I've got your back, and I will move data from this system to that system.
Now, in the mid 21st century, having a robust polling API is legacy. Putting reports onto an SFTP server or S3 bucket for others to pickup, that's a dying philosophy. It's table stakes and it doesn't demonstrate a modern company. PointCast (deep cut) had it right in the mid-nineties. Modern system integration philosophy is about push. If your product generates the data, it's your products responsibility to push that data to other systems in the way they can receive it. This could be via a webhook through RESTful JSON or it may even being pushing a file over SFTP. But ultimately, he who generates the data MUST send it outward. The concept of "I have an API others can call into to get data" marks you as a legacy company with a legacy philosophy. The world has moved on.
This doesn't solve the square peg / round hole problem. If your software pushes out a webhook, what format is it? It's square. Almost certainly the company receiving it doesn't have a square hold to accept it. So now what? An industry has formed around this as a "customer data platform" whose business is to transform square JSON pegs into round JSON holes. Good for them.
The real concept different in the past two decades is that your product has to own pushing your data into the ecosystem. Tally-ho.