How to Connect Business Software When There Is No API

Available connection methods

Check the documentation and administrator settings for the exact product edition in use. Ask the vendor about APIs, webhooks, scheduled reports, bulk exports, imports, secure file transfer, and approved marketplace connectors. A feature shown on a vendor site may require another plan or separate permission.

For a marketplace connector, review its requested permissions, data storage, retention, support owner, and failure reporting. A listing in the marketplace does not answer those questions. Record each vendor answer and the date it was checked.

Use a vendor-supported connector, import, export, or secure file transfer when one meets the requirement. Scheduled files can suit delayed, mostly one-way data. Browser automation needs tighter limits and ongoing maintenance. Manual handling may remain reasonable when volume is low or an automated write would carry too much risk. Avoid building on undocumented endpoints that the vendor can change without notice or may not permit.

What needs to move

Name the record that needs to move, the trusted source, the destination, and the required update schedule. Also decide whether the destination only displays the data or sends a change back.

A one-way daily list can often work from an export. Updating orders or customer records in the source system carries more risk because the connection needs permission to write, a way to prevent duplicate changes, and a record of what it changed.

Preserve the source system's unchanging record ID in the destination when possible. If the systems have different IDs, maintain a reviewed mapping table. Names and email addresses can change or appear on more than one record, so they are weak identifiers for an automated write.

Define what happens to corrections, cancellations, deletions, merged records, and fields edited in both systems. Record which system controls each field or operation and which conflicts require review.

• Fields required for the destination task
• Source identifier and destination mapping
• Acceptable age of the data
• Person responsible for rejected or uncertain records
• Correction process when the source changes later

When scheduled files are enough

A recurring CSV or spreadsheet export can support reporting, review queues, and other one-way work. Prefer an export produced by the source system on a known schedule. Store it in a controlled location and limit access to the people and services that need it.

Test the actual file across several runs. Check whether column names, date formats, time zones, blank values, and identifiers remain consistent. If a report arrives by email, decide who owns the mailbox rule and what happens when the attachment is missing.

Classify the exported data and use transfer and storage locations approved for that information. Set retention and deletion rules for source files, email attachments, screenshots, logs, and rejected rows. Routine logs should contain record identifiers and status where possible instead of full sensitive values. Mailbox forwarding, attachment access, and mailbox retention need the same review.

The destination should show when the source file was created and when it was processed. Someone reading Monday's data on Tuesday needs to see that delay.

Browser automation needs operating controls

When the only available path is a website, browser automation may be able to download a report or enter a limited set of records. Check the vendor's terms and support policy. Request written confirmation when the planned use is unclear. Restrict the account to the required screens and actions.

Use a vendor-approved service account when available. Do not bypass multifactor authentication or place a person's shared credentials in the automation. Store secrets outside source code and runbooks, and assign someone to rotate and revoke them.

Screen layouts, labels, login flows, multifactor prompts, and session rules can change. Keep the job narrow and record attempted and confirmed changes under a stable operation ID. Set a limit on records changed per run. Use a test environment, dry run, or approval step for higher-impact writes when the software provides one.

A timeout after submission creates an uncertain result because the change may have succeeded. Pause before retrying. Check the destination record, status screen, or confirmation tied to the stable ID. Send the case to a person when success cannot be confirmed. Test a duplicate submission, a timeout after submission, and a restart during a batch.

Duplicates, corrections, and stale inputs

Test an identical resend, a corrected resend, an incomplete file, a changed column, an empty report, and a late correction. Use the source record ID with a source version, modification time, file ID, or content comparison to distinguish an unchanged duplicate from a correction.

Define whether a changed repeat updates the destination, waits for review, or is rejected. Keep rejected rows available under the retention rule and make their reason visible to the person responsible.

Do not let a partial import look complete. Record the number of rows received, accepted, rejected, and skipped. For financial or inventory data, compare the totals or counts that matter to the business before the result is used.

Ownership and maintenance

File and browser connections still need an owner. Record the service account, schedule, expected-arrival deadline, freshness threshold, storage location, alert recipient, retry rule, and manual recovery steps without placing secret values in the runbook.

Alerts should distinguish a missing input, stale file, rejected rows, partial import, uncertain write, and complete job failure. A run that processes yesterday's unchanged file should not report the data as current.

Set a review date. Recheck whether the vendor added a supported connection, changed the export, or altered the login process. A workaround that nobody owns can keep running with stale information long after its last successful test.

Before launch

Compare the connection's maintenance cost with the cost and risk of the manual process it replaces. A daily export with a visible timestamp may be sufficient for one decision. A fragile write-back process may deserve a supported vendor connection or a different system.

Assign someone to receive failure alerts and document what that person should check next. Run the recovery steps once before the connection is left on its regular schedule.