It is the third system finance has asked you to bring into the report this year.
The first two were in the tool catalog and took an afternoon each. The third is a contract management system that only your company and a handful of others run. The problem is that a connector catalog is a finite list, and your source never made it on.
In this article we explain the three ways out when the source sits outside the catalog, what a connector has to solve before it becomes a table, and what the promise of a new connector charges you.
Export by hand, ask the vendor, write the integration
When the name is not on the list, the conversation usually ends in one of three options. It helps to recognise each one before choosing by elimination.
- Export by hand. Somebody downloads a CSV every Monday and drops it in a folder. It works in week one, depends on a person remembering in week ten, and the report carries the date of the last time they did.
- Ask the tool vendor. It becomes a backlog item and comes back with a timeline in quarters. That makes sense when the source is popular enough to serve other customers, and none at all when the source is yours alone.
- Write the integration. Somebody codes the API read, handles pagination, stores the token and schedules the run. It is the way out that actually solves the problem, and exactly the one a team of one or two people without a programmer cannot sustain.
The third is the only one that delivers fresh data without depending on anyone remembering. It is also the one most people abandon halfway, because writing the first version is easy and maintaining the tenth is not.
The bill arrives at maintenance.
What a connector has to solve on its own
A connector is not an HTTP call. Between a JSON response and a table Power BI can read sits a list of problems somebody has to solve, and it is always the same list.
Authentication is only the front door. Airbyte published on August 28, 2026 that managed authentication has become the market baseline rather than the differentiator. After it come pagination, request limits per minute, field types, and what to do when the response changes shape.
Then there is the catalog. An API returns nested documents; a table wants columns with declared types. Somebody has to decide what becomes a column, what becomes a separate table, which field is the key and which date marks the next read.
A concrete example
A carrier wants the average resolution time of support tickets in the weekly report. The API returns each ticket with a list of interactions nested inside. Without deciding that an interaction becomes its own table, keyed by ticket identifier, there is no SQL query that answers the question.
The question shapes the catalog.
What the promise of a new connector costs
Generating a connector from documentation removes the repetitive work, and does not remove everything. It pays to know where it stops before relying on it.
The connector inherits the quality of the documentation. If the specification describes a field as text and the API returns a number, whatever generates from it gets that wrong too. Stale documentation is the most common defect, and it only surfaces on the first load that carries real data.
Unusual authentication also blocks the path. Request signing, client certificates and two-step approval flows do not fit the usual shapes, and no automatic generation invents a protocol nobody wrote down.
And there is the difference between being in the catalog and being reachable. The management systems most used in Brazil have no ready-made connector on the Januss list. That is one thing, and it is true.
They are reachable through the API documentation path, which is another thing, and the place it shows up is the same configuration screen. Confusing the two is expensive in both directions: it makes you give up on a source you could connect, and it makes you promise a connector that does not exist.
Ask about the path, not the list.
Where Januss comes in
In Januss the path for a source outside the catalog is pointing at the API specification or pasting its documentation. Out of that come the connector and the table catalog, with authentication and pagination handled without you writing glue code.
There are six authentication shapes, named one by one. None, API Key, HTTP Basic, Bearer, a login that returns a token, and OAuth 2.0 with client credentials. Outside those six, the answer is not to generate and hope, but to recognise that the source calls for a different conversation.
Before saving, Januss makes a real call and only finishes if it can read the data. That changes the moment you find out the documentation was wrong: on the configuration screen, and not on the Tuesday the report wakes up empty.
The AI writes the connector once. After that the extraction is deterministic and runs the same way every time, with no AI in the data path, which is what lets you trust next month numbers. The ready-made Harvest connector runs on that same engine.
Want to try it against the source that got left out? The 14-day trial asks for no card, and you can paste the API documentation and watch the catalog appear. Create your Januss workspace.
Sources
The reading that managed authentication has become the market baseline comes from the Airbyte blog:
Create your workspace in minutes.
Point at your source and watch the data reach the database the same day.