Getting a sanctioned route in writing: an official export, a supported file drop, a granted read replica or a partner integration - before screen automation.
Key takeaways
- The difference between a sanctioned route and a tolerated one is a document, not a technology. Get the answer in writing before a line of code.
- The partner or professional-services route is the option most businesses never check, and the only one that arrives with a commitment from the vendor.
- A view or read replica the vendor granted is a different thing from direct access you took yourself, even when the query is identical.
- Screen automation breaks silently: the script "succeeded" after filling the wrong field.
- Whether it is permitted under your agreement is a question for you and your lawyer, not a technical question.
When a supplier has no API, the first question is not technical but who sanctions what. There are five routes a vendor can approve in writing - an official export, a file drop they support, a granted view or read replica, an integration through a partner, and paid development by the vendor. Screen automation is not one of them, and it comes last for good reasons.
The email that decides which options exist at all
Before evaluating solutions, send five questions in writing to somebody at the vendor with authority to answer. The replies narrow the discussion immediately:
- Which programmatic interfaces exist in the edition and version we are licensed for?
- Is there a scheduled or automated export we can enable ourselves from inside the product?
- Will you grant a read-only view or a read replica of our data, and on what conditions?
- Do you, or a certified partner, deliver integrations as a paid service?
- Who at your company is authorised to say what our agreement permits regarding automated access?
The fifth is the one people skip, and it is the only one that decides whether you may start. An answer from a support agent is not an answer - you need somebody who can commit, and the reply has to stay in writing, because in a year somebody will ask.
What separates a sanctioned route from a tolerated one?
A tolerated route is one that works today and nobody committed to. Five tests separate them:
- Documentation. Somebody at the vendor approved the route in writing and you can point at the document.
- Upgrade survival. The route is defined as an interface, so a version change should not break it without notice.
- Its own credential. There is a dedicated integration user or key, not a real employee's password.
- Loud failure. When something breaks you get an error, not partial data that looks fine.
- Ownership. There is a person's name - at your end and at the vendor's - responsible for fixing it.
A route that fails three of these is not a solution but a loan from the future. You can take that loan deliberately, provided it is written down as one.
The five sanctioned routes, side by side
| Route | What you need from the vendor | What can break it | What it suits |
|---|---|---|---|
| Official export or report | Enablement in settings, documented format and schedule | A format change in a version upgrade | Reports, periodic sync, data retention |
| A file drop the vendor supports | Destination, naming convention, write-completion marker | A change to names or encoding | Structured transfer between systems |
| Granted view or read replica | Read-only permission and a field dictionary | An internal schema change | Reporting, BI, data exploration |
| Integration via a certified partner | A written scope and a version-compatibility commitment | The partner engagement ending | A business process that also needs writes |
| Paid development by the vendor | An agreed specification and support terms | Their internal prioritisation | A specific need with no off-the-shelf answer |
Note the third column: no route is immune. The difference is that in four of them a break is an event with an address, and in screen automation it is an event that is entirely yours.
What does a partner or professional-services integration actually buy?
It buys three things you cannot write in code: an interface somebody commits to supporting, a commitment about compatibility with future versions, and an address to contact when it breaks. It also costs money, turns the project into a purchasing decision rather than a technical one, and introduces a dependency on a third party's availability.
If you take that route, these are the clauses worth having in the scope of work:
- An explicit list of fields and entities, not "the relevant data".
- The direction per field: read, write, or both.
- A commitment covering what happens on a product version upgrade.
- Whether a test environment exists and who supplies its data.
- Who fixes a fault after handover, and within what response time.
- Who owns the documentation and the field mapping at the end of the project.
The last one is the one people forget, and it is the one that decides whether you can change supplier later.
Screen automation: the caveats, unvarnished
Screen automation is a program that drives the software as a user would. It comes last because it brings five problems the other routes do not have:
- Fragility. A moved field, a new dialog or an interface refresh knocks it over.
- Silent breakage. The program completes successfully after filling the wrong field, and nobody knows until someone spots a wrong figure in a report.
- Credential handling. It usually needs a real user's password, so actions get attributed to a person who did not perform them and two-factor authentication becomes an obstacle.
- Audit and accountability. There is no separate record distinguishing a human action from a program's action.
- Terms of use and the agreement. Your terms of use and your contract with the vendor are what decide whether automated access is permitted at all.
That last caveat is not a technical question and has no general answer. It is set by your agreement with the vendor and the terms that apply to you, which is why it goes to you and to a lawyer rather than being settled in an article. And where a system explicitly blocks automated access, there is nothing here to solve technically.
What every non-API route needs, whichever you pick
These routes deliver data, but none of them will tell you it has stopped. That means you need your own detection layer:
- A freshness check. If no new data arrived inside the expected window, somebody gets an alert.
- An expected volume band. A record count outside the historical range halts the load instead of entering it.
- A signature of the last input. A file identical to the previous one is a sign the source did not update.
- An escalation contact. A name, not a role.
- A way to reverse a day's load. Defined in advance, because once wrong data is in it is too late to design one.
Related: what to do when a system has no API, scraping versus an API, the considerations around web scraping in Israel.
Sources
Frequently asked questions
The vendor said there is no API. Is that the end of it?
Not necessarily. Ask three more questions in writing: which interfaces exist in our edition, whether there is a paid integration module, and whether a scheduled export exists. Vendors sometimes say "no API" when they mean there is none in the edition you purchased.
What is the difference between a granted view and a direct database connection?
A view the vendor defined is an interface: it hides the internal structure, gives you agreed fields, and the vendor knows you depend on it. Connecting straight to tables is a dependency on an internal detail nobody committed to, and a version upgrade can change it without notice.
Is screen automation allowed?
That is not a technical question. What decides it is the terms of use and your agreement with the vendor, and those differ between vendors and between contracts. Put the question to the authorised person at the vendor and to your own lawyer, and get the answer in writing before you build.
How do you know a file route has stopped working?
Not from the run succeeding but from the data. Set a freshness check that alerts when no new file arrived inside the expected window, a volume band that halts an abnormal load, and a signature comparison against the previous file to catch one that repeated itself.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.