Data Has to Go Somewhere
Getting data in is the part everyone plans for. Getting it back out — into the warehouse, the storage account, the BI tool, or the system that actually triggers something — is where integration projects quietly stall.
Integration projects are planned around getting data in.
That is where the diagrams start, where the connector list gets scrutinised in the evaluation, and where the first two weeks of work go. Sources are the part everyone thinks about.
Then the data is clean, joined, checked and correct — and it needs to be somewhere else. In the warehouse the analysts use. In the storage account the finance system reads. In the BI tool half the company already has open. In the system that will actually do something when a number crosses a line.
That second half is where projects stall, and it stalls quietly, because "we have the data" feels like the finish line right up until somebody asks how it gets to where it is needed.
Where prepared data can go
Databases and warehouses, natively: Postgres, MySQL, SQL Server, BigQuery, Redshift, Elasticsearch — plus SFTP.
Cloud storage: SharePoint, OneDrive, Azure Blob Storage.
BI: Tableau.
And anything else, over REST.
That last one is the interesting entry, and it is worth being precise about why.
Two-way REST is a different thing from an API
Most platforms have a REST API. It means you can pull your data out if you are prepared to write something that does the pulling.
REST API Export is the other direction: Mammoth pushes dataset data to an external REST endpoint using POST, PUT or PATCH. It shipped in June 2026, and what it completes is two-way REST connectivity — the REST connector already handled import, and this closes the loop.
The practical difference is who has to build. With import-only REST, reaching an internal system means someone writes a job that polls Mammoth, handles auth, manages state, and gets maintained forever by whoever drew the short straw. With export, the endpoint you already have is the integration.
That covers the long tail that no connector list will ever reach: the internal tool, the ops system, the thing your team built in 2019 that everything quietly depends on. Those never appear in a vendor's supported-sources page and they are frequently the ones that matter most.
Why the destination list looks the way it does
There is a pattern in what is on that list, and it is not "the most popular products".
It is the places prepared data actually has to land: the warehouse someone reports from, the storage account another system watches, the BI tool that is already deployed, the SFTP endpoint a partner insists on because they have insisted on it since 2011.
Cloud storage matters more than it sounds. A file landing in SharePoint or OneDrive or Azure Blob is often the interface to a system that has no API at all — a finance process, a partner exchange, a scheduled import somebody set up years ago and nobody wants to touch. Writing a file into a folder is an unglamorous integration and it works, which is why it survives.
The part worth designing deliberately
Destinations are where the question of when becomes real.
Data that is correct but delivered at the wrong moment causes a specific kind of confusion: two systems holding different versions of the same number, both of them right at the moment they were written, and nobody able to say which is current. Deciding what flows automatically, what waits for a person, and what should stop entirely when a check fails is a design decision — and it is easier to make once, up front, than to retrofit after the first disagreement in a meeting.
The upstream machinery exists for exactly this. Checks that halt a pipeline stop bad data before it reaches a destination rather than after. A refresh that rejects a mismatched schema protects what is already there. Those only pay off if the delivery step is wired into them deliberately rather than bolted on at the end.
The unglamorous conclusion
Nobody chooses a data platform because of its destination list.
They choose it for the connectors, the transformation, the AI, the dashboards. Then, three months in, the project's actual blocker turns out to be that the cleaned data cannot get into the one system that needed it, and someone starts writing a script that will still be running unmaintained in four years.
Worth checking early. It is a boring question that decides more than it should.
