How to Automate Software Without an API

You can automate software without an API, often without replacing it. First check whether it can export reports or import files. If those routes cannot do the job, screen automation can operate the application on a user's behalf, but it needs a reliable way to confirm what completed.

An API is a connection that lets software exchange information directly. Its absence does not mean staff must keep copying every customer detail or job line by hand. A supported file import may remove most of that work while leaving the existing system in place.

I would prefer a supported file import with a clear rejection report over a robot that clicks through the same entry screens. Where neither route can reliably confirm which records were accepted, automate preparation and keep final submission manual.

Start with one task and its required outcome

Choose a specific piece of admin, such as entering approved jobs into an accounts package. Avoid starting with a broad goal like “automate the accounts system”. Watch someone complete the task, including the checks they make before saving.

Record these practical requirements:

• Direction: does information need to come out of the application, go into it, or both?
• Fields: which customer references, dates, amounts and approval details are required?
• Frequency and volume: how many records arrive, and can they wait for a daily batch?
• Decisions: which steps follow fixed rules, and which need a person's judgement?
• Confirmation: how does someone know a record was saved correctly?

The timing requirement can change the answer. A daily export may suit invoice preparation but be unsuitable for a booking process that needs current availability. Likewise, generating a draft is a different risk from posting an invoice or releasing a payment.

Check supported routes before automating the screen

Look in the software's menus and documentation for imports, exports, scheduled reports, batch entry and existing connectors. Ask the vendor about the exact version and plan you use. A feature available elsewhere in the product range may not be enabled in your installation.

Check both ends of the task. An export of approved jobs is only useful if the accounts package can accept the required fields, or if it removes enough preparation work to justify retaining manual entry. A PDF report may help a person read the data but still leave substantial conversion work.

Ask the vendor to demonstrate:

• The supported file format, required columns and permitted values.
• Whether reports can be scheduled and where files can be delivered.
• What happens when one record in an import is invalid.
• How accepted records, rejected records and duplicates are identified.
• Whether the proposed access and automation are permitted under the licence.

Do not assume direct access to the application's database is a safe shortcut. Writing there can bypass the checks performed by the application. Use only a vendor-supported method with a defined recovery process.

Use file exchange when its timing and checks fit

A file workflow usually has four parts: export the approved information, check it, convert it into the receiving format, then import it. Depending on the software, staff may still need to download or upload the file. Removing the copying and checking can still make this worthwhile.

The safeguards matter as much as the transfer. Check that the file is current, its columns have not changed and required values are present. A missing file must trigger an exception, not be treated as a successful run with nothing to process. Retain the original file and a record of what was submitted.

A practical guide to legacy-system automation similarly recommends checking scheduled exports and imports before screen automation, with validation, duplicate detection and retained raw files as safeguards.

Do not assume an import is all-or-nothing. Establish whether the application rejects the whole file or accepts valid rows and rejects the rest. Staff need a way to account for every submitted record, using an acceptance report, rejection report or a dependable check against saved records.

Use a stable reference, such as an approved job number, to match the source record to its destination. Check whether the receiving software actually prevents duplicate references. If it does not, the workflow needs its own check before resubmission. A record of attempted submissions alone cannot prove that they succeeded.

Use screen automation only where completion can be verified

Robotic process automation, usually called RPA, operates software through its user interface. Microsoft's desktop automation documentation describes actions that interact with Windows applications through clicks, keystrokes and identifiable interface elements, including extracting data.

This can be useful when the application has no suitable import and the task follows a stable sequence. Prefer identifying a named field or button to relying on a fixed position on the screen. Even then, login prompts, unexpected windows and interface changes need explicit handling.

The automation should wait for a recognisable outcome after each important action. “The save button was clicked” is not enough. A saved record number or a reliable search for the submitted job reference provides stronger confirmation.

Access also needs planning. Confirm who owns the account, how credentials are protected, what happens when a session expires and who maintains the process after an application update. Running unattended has additional platform and access requirements; it is not simply an attended process with the person removed. Microsoft's desktop-flow requirements distinguish attended and unattended operation.

For this kind of automation and integrations work, recovery should be part of the initial design. If a run stops after saving a record but before recording success, it must check the destination before trying that record again.

Worked example: approved jobs into an older accounts package

Illustrative scenario: an operations team exports approved jobs each afternoon. Staff then enter the customer account, job reference, description and approved charge into an older accounts package. Assume daily processing is sufficient and the customer account codes already match.

If a supported import exists: prepare the required file, validate the account codes and charges, and let a staff member review the batch before importing. Suppose the package reports accepted and rejected job references. Staff can correct the rejected rows and resubmit only those, after checking that none were already accepted. This would be my first choice.

If only screen entry is available: a desktop process could open each customer account, enter the job and save it. After every save it would need to capture the resulting record reference or find the saved job reliably. An interruption would leave completed, failed and uncertain items for review. Staff would reconcile uncertain items before restarting.

The recommendation changes if the package permits duplicate job references and offers no dependable way to find a recently saved entry. In that case, unattended screen entry creates an avoidable retry risk. Prepare and validate the job details automatically, but retain a controlled manual entry or submission step until acceptance can be checked reliably.

A route-selection checklist

• Choose supported file exchange when the export and import cover the required fields, batch timing is acceptable, and accepted and rejected records can be reconciled.
• Consider screen automation when no suitable supported transfer exists, screens are sufficiently stable, access is permitted and saved records can be verified before retries.
• Keep a manual checkpoint when approval requires judgement, actions have significant consequences, or partial completion cannot be reconstructed confidently.
• Reconsider the system when neither route meets the required timing or reliability, or ongoing maintenance would outweigh the value of retaining it.

Include setup and continuing support in the decision. File formats can change as well as screens. Name the person who will review exceptions and the person responsible for repairing the workflow.

Prove recovery in a small trial

Start with a limited batch, ideally in a test environment. If that is unavailable, agree a controlled live trial with the person responsible for the records. Define these acceptance tests before building:

• Valid record: the saved values match the approved source, and its destination reference is recorded.
• Rejected record: a missing field or invalid account code produces a visible exception without being marked complete.
• Duplicate: submitting the same source record again does not silently create another entry.
• Interrupted run: stop after a save but before success is logged. The recovery procedure identifies whether that record exists before retrying.
• Changed input or screen: an altered file column, unexpected pop-up or moved control causes a safe stop rather than guessed entry.
• Missing input or expired login: the responsible person receives a clear failure notice rather than a success message.

Accept the trial only when staff can account for every source record as completed, rejected or awaiting review. Software without an API can often stay in place, but the useful stopping point may be automated preparation rather than unattended submission.