A system without an API can still be integrated through other supported routes: scheduled file exports and drops, vendor connectors or standards such as EDI, read-only database views, email parsing and, as a last resort, screen automation. Choose the most stable, vendor-supported route, then wrap it with validation, duplicate protection and reconciliation.
The question usually arrives in this form: "How do I sync invoice and payment data between a procurement platform and my ERP when there's no API?" A missing API is a constraint on how data moves, not a reason to keep re-typing it. This guide is for CTOs, engineering leads and IT directors who own such a system. It ranks the options by how much risk they carry, shows how to build the safest one properly and says when to stop and replace the system. For the wider choice of integration styles, see system integration approaches and the enterprise integration patterns decision guide. For help building the link, see our systems and API integration service.
Key takeaways
- Confirm that no API exists. Many products have an API on a higher plan, a partner connector or an export schedule that nobody has enabled.
- Prefer routes the vendor supports: scheduled exports, SFTP drops, standards such as EDI, and vendor connectors.
- Never write directly into another product's database. Read-only views are acceptable only where the vendor permits them.
- Email parsing and screen automation are fragile. Use them only when nothing better exists, and plan their replacement.
- Every non-API route needs the same four controls: validation, duplicate protection, error handling and reconciliation.
- If the integration will be permanent, a system with no API is a candidate for replacement.
Does the system really have no API?
Check before you build. A product may expose an API only on a higher plan, offer a documented import and export format, provide a marketplace connector, support a standard such as EDI or cXML, or let administrators schedule report exports. Ask the vendor in writing, and read the licence terms before automating anything.
A short checklist:
- Search the vendor's documentation for "API", "webhook", "export", "import" and "integration".
- Ask the vendor: is there an API on any plan, on a roadmap, or available to partners?
- Look for scheduled report exports to SFTP or email, and for bulk import templates. Ask whether a bulk data export or reporting feed exists.
- Ask whether the platform supports business-document standards. In procurement, EDI (ANSI X12 transaction sets such as 810 invoice, 820 payment order or remittance advice and 850 purchase order, or UN/EDIFACT messages such as INVOIC) and cXML are common, though support varies by product.
- Read the terms of use. Some prohibit automated access to the user interface.
What are the options, and how do they compare?
The options form a ladder from stable to fragile. Vendor connectors and standards sit at the top, scheduled file exchange comes next, read-only database views follow, and email parsing and screen automation sit at the bottom because small changes by the vendor can break them silently.
| Option | How it works | Strengths | Main risks |
|---|
| Vendor connector or marketplace app | Product supports a link to your ERP or middleware | Supported, maintained by the vendor | Limited fields, plan restrictions |
| Standards (EDI, cXML) | Structured business documents exchanged by agreed format | Stable, auditable, widely understood | Setup with trading partners; not every product supports them |
| Scheduled file export and drop | System writes CSV or XML to SFTP; integration picks it up | Simple, vendor-supported, easy to test | Batch latency; file format drift |
| Scheduled data export or reporting feed | Vendor writes a full or incremental dataset to storage or a warehouse | Complete data, vendor-supported | Often a higher plan; not real time |
| Read-only database view or replica | Integration reads from a view you or the vendor provide | Fast, complete data | Only where permitted; load on source; schema changes |
| Email parsing | Notification or attachment emails are read and parsed | No access needed to the system | Wording changes break it; spoofing; PDF extraction errors |
| RPA or screen automation | A robot clicks through the user interface | Works when nothing else does | Breaks on UI changes, sign-in challenges and timeouts; terms-of-use risk |
How do you build file-based integration properly?
Treat each file like a message with a contract. Agree the format, name files with a sequence number, write them atomically, include control totals, validate on arrival, import idempotently and archive everything. A reliable file exchange is mostly discipline at the edges, not clever code.
- Atomic drop. The sender writes to a temporary name and renames to the final name when complete, so the reader never picks up half a file.
- Naming and sequence. Use a pattern with date and sequence, such as a prefix, run date and number. A gap in the sequence is an alert.
- Control totals. Include a row count and an amount total in the file or a companion file. Compare them before import.
- Format rules. Fix the encoding (UTF-8), delimiter, quoting, header row, decimal separator, and the date and time zone convention. Format drift is a common cause of "random" import errors.
- Idempotent import. Use the document number and supplier as a key. Re-importing the same file must change nothing.
- Reject file. Invalid rows go to a reject report with the reason; valid rows still load, unless the business requires all-or-nothing.
- Acknowledgement. Return a file or message that says what was accepted and rejected, so the source system's owner can see it.
- Security. Use SFTP with key-based authentication and restricted folders, not plain FTP, and consider file-level encryption if the files hold sensitive data.
When is reading the database acceptable?
Reading a database is acceptable only when you own the system, or the vendor explicitly supports read-only access through a documented view or replica. Writing directly is not acceptable: it bypasses the application's business rules, can corrupt data and may breach the support terms.
If reading is allowed, give the integration a read-only account restricted to named views, not tables. The view becomes a contract that you can keep stable when the underlying schema changes. Read from a replica where possible, so reporting-style queries do not slow the transactional system. Mask or exclude personal data you do not need. Most hosted software-as-a-service products do not expose their database at all, so for those this route does not exist.
How reliable is email parsing, and when does RPA make sense?
Email parsing and robotic process automation (RPA) both depend on presentation that the vendor can change without notice. Use email parsing for structured system notifications, never for free text, and use RPA only for low-volume, low-risk tasks until a supported route exists.
For email, use a dedicated mailbox, accept only messages from verified senders, parse by template, send anything that does not match to a review queue and keep the original email as evidence. For scanned or free-form invoices attached by email, extraction needs a document-processing step; see our intelligent document processing guide.
For RPA, check the terms of use, run the robot under a named service account with the least access it needs, store credentials in a secrets vault and not in scripts, and log screenshots on failure. Expect breakage whenever the vendor changes a screen, adds multi-factor sign-in or changes timing.
Which option fits which situation?
Match the route to what the vendor actually supports, not to what is easiest to build. The table below maps common situations to one recommended route, so you can check your own case against the nearest row. Where two routes both work, the ranking in the options table above decides.
| Situation | Recommended route |
|---|
| Vendor offers a connector for your ERP | Use it, and map fields you need through middleware if the connector is limited |
| Both sides support EDI or cXML | Use the standard; it is built for invoices and payments |
| Platform can schedule exports and accept bulk imports | File exchange over SFTP with controls |
| You host the system and own the schema | Read-only views, with writes only through the application's import tools |
| Only notification emails exist | Parse emails into a review queue, and ask the vendor for exports |
| Nothing else works, volume is low, task is stable | RPA with monitoring, plus a replacement date |
| Integration is permanent and business-critical | Plan to replace or wrap the system; see legacy system modernization options |
Worked example: syncing invoice and payment data without an API
This example is illustrative; the numbers are invented.
A company runs a procurement platform with approval workflows and an ERP for accounts payable. The platform has no API but can schedule an "approved invoices" report to SFTP and accept a bulk upload of payment status.
- Export. At 22:00 the platform drops a CSV of approved invoices, say 150 rows, with a row count and total in a footer.
- Validate. The integration checks the controls, then each row for supplier, purchase order, currency and tax. Three rows fail, perhaps for an unknown supplier code, and go to a reject report that procurement fixes the next morning.
- Map. A cross-reference table converts platform supplier IDs to ERP vendor numbers. The table has an owner, because stale mappings are a common cause of rejects.
- Post. The 147 valid invoices are created in the ERP through its import service or API, keyed by supplier and invoice number so a rerun cannot duplicate them. The ERP applies its own matching of purchase order, receipt and invoice.
- Pay. The ERP payment run happens as normal.
- Return. The ERP's paid invoices are written to a file in the platform's bulk-upload format and uploaded on a schedule, so approvers see "paid" without asking finance.
- Reconcile. Each morning a report compares invoices approved, posted, rejected and paid, by count and amount. The totals must agree, or an alert goes to the owner.
Can an iPaaS reduce manual entry between ERP procurement and vendor portals?
Yes, as an orchestration layer, but it does not create an API. An integration platform can pick up files, parse emails, call the interfaces that do exist, map fields, schedule runs and provide monitoring and replay. The access route still has to exist on the other side.
Use the platform for what it is good at: connectors to the ERP, a mapping tool, scheduling, error queues and dashboards. Keep the supplier-facing portal's own functions for supplier registration and invoice submission, and integrate its outputs into the ERP. Whichever tool you choose, the controls in this guide still apply.
What are the main risks across all non-API routes?
Every non-API route shares the same risks: silent format changes, duplicates, missed runs, exposed data, shared credentials and dependence on one person. Each has a standard control, and building them in is what separates a dependable integration from a fragile script.
| Risk | Control |
|---|
| Silent format change by the vendor | Schema checks on every file; alert on unexpected columns |
| Duplicate postings | Natural keys, idempotent import, reconciliation |
| Missing runs | Heartbeat alert when an expected file does not arrive |
| Sensitive data in files and mail | SFTP, restricted folders, retention limits, masking |
| Shared or personal credentials | Named service accounts, vault, rotation |
| Key-person dependence | Documented mappings, runbook, tests |
| Terms-of-use breach | Written vendor confirmation before automating |
When is this the wrong approach?
Do not build an elaborate integration around a system you plan to replace within months; a controlled manual upload with validation may cost less. Do not use RPA for high-volume or financially critical flows. If the vendor can provide an API on a different plan or release, buying that may be cheaper than maintaining workarounds. And if the missing API blocks several projects, treat it as evidence that the system is a candidate for replacement.
Glossary: EDI, the exchange of structured business documents between systems in an agreed format; SFTP, file transfer over SSH; RPA, software that operates a user interface like a person; cXML, an XML standard used in procurement for orders and invoices.
How Timeline Digital approaches closed systems
When a system offers no API, Timeline Digital starts the Plan step by checking which routes the system actually supports, prefers vendor-supported ones, scopes validation and reconciliation, and tells you plainly when a system should be replaced. Timeline Digital was founded in 2013, is based in Islamabad and delivers remotely. A free pilot of 2 to 3 key modules lets you test the result before the final agreement, schedules are set from your requirements in the Plan step, and the code is handed over on full payment. See ERP integration services for ERP-centred work.