How to Connect Software Without APIs

Written by Laurent Léveillé, Senior Community Manager at Deck

Not every system has a public API. A huge amount of business-critical data lives behind login walls: legacy utilities, government portals, insurance carriers, ERP platforms, HR systems. Most of these systems were never built to expose a developer-accessible endpoint. There are still reliable ways to connect to them. Deck gives products secure, programmatic access to web interfaces while handling login flows, session state, and structured data extraction through a single API.

Why the API Gap Exists

APIs are expensive to build and maintain. Not every organization has the engineering capacity or business incentive to expose their data programmatically. Some systems are decades old and were built in eras before APIs were standard. Others simply don't prioritize developer access as part of their business model.

This means many critical data sources remain accessible only through their front-end interfaces — the same pages a human user would interact with. Automation tools can interact with these pages in the same way as a user, often handling forms and navigating JavaScript-driven content to extract or submit data.

Your Options for Connecting Without an API

Understanding Direct Database Connections

One of the most direct ways to integrate a legacy system that lacks an API is a direct database connection. This lets a receiving system, such as a modern web app, connect straight to the database of the source system, using SQL queries to retrieve, update, or share data. If you're dealing with fragmented data across multiple systems, a direct database connection can give you a practical way to integrate and access critical information.

For example, imagine you have an older system that stores customer records in a traditional database. If you want to connect this data to a new web app, you can implement a direct database connection. The web app would use secure credentials to access the database, run SQL queries, and pull the necessary customer data, integrating without an official API. This can be especially valuable when you're modernizing workflows or giving users up-to-date information from legacy systems.

However, while direct database connections offer a straightforward integration path, they come with important security considerations. Use secure connection protocols like SSL/TLS to protect data in transit, and restrict database access with strong credentials and network access controls. Limiting user permissions and creating database views can help ensure that only the necessary data is exposed to the receiving system, reducing the risk of unauthorized access.

In some scenarios, direct database connections may not be possible — perhaps due to strict security policies, technical limitations, or the risk of impacting the performance of the source system. In these cases, alternative integration methods such as screen scraping or middleware solutions can be used to bridge the gap.

Option 1: Wait for an Official API

Sometimes waiting is the right call — but it often isn't. API roadmaps at large companies move slowly, and there's no guarantee a public API will ever ship for the specific functionality you need. In fast-moving product environments, waiting isn't a strategy.

Option 2: Build Your Own Web Automation

Screen scraping and browser automation (tools like Selenium, Puppeteer, or Playwright) can technically access any web-based system. These tools simulate user clicking, navigating from page to page, and interacting with forms on the site, often dealing with JavaScript-heavy content.

• Websites change constantly. A redesign or even a minor CSS update can break your entire script.
• Authentication is complex. MFA, CAPTCHA, session tokens, anti-bot detection, and submitting login data via POST requests all stand between your script and the data.
• Maintenance never ends. The script you build today needs ongoing monitoring, debugging, and revision, including continually parsing changing page structures and handling updates to forms and JavaScript.
• Scaling is painful. Running automation across thousands of users introduces performance and reliability challenges most teams aren't built to handle.

Option 3: Use a Browser-Native Agent Platform

If you're connecting software without APIs, Deck is a production-ready alternative to custom automation. Instead of building and maintaining scripts for every application, you integrate once through the Deck API while Deck handles the underlying browser interactions. If you're comparing browser infrastructure options, see our guides to Browserbase alternatives and Anchor Browser alternatives.

How Deck handles everything that makes web automation hard:

• Authentication: Deck manages login flows, MFA, CAPTCHA, and session handling for over 100,000 portals.
• Resilience: Deck's agents are self-healing and adapt to UI changes automatically.
• Security: All sessions are user-permissioned and run in a secure, compliant environment.
• Reads and writes: Deck supports both data extraction and actions like form submissions, payment updates, and document uploads.

How It Works in Practice

Imagine you need to connect your product to a utility provider’s billing portal. There’s no API. The only access point is through the provider’s website.

With Deck:

• The user authorizes the connection through a consent flow.
• Deck logs in using the user’s credentials in a secure browser session.
• Deck navigates to the billing section, extracts the relevant data, and returns it as structured JSON.
• If the portal layout changes, Deck detects the change and adapts automatically.

For cases where browser-based access is not possible at all — for example, a portal that actively blocks automation or requires physical hardware authentication — you can request an export from the portal, download the file to a secure server via SFTP, and parse the CSV or XML data for integration with your system.

Another common method is email-based integration. Here, a system sends emails with structured data such as CSV attachments or formatted content in the email body, and another system monitors an inbox and parses these emails for relevant information. Many iPaaS solutions also offer pre-built connectors for popular legacy systems, allowing integration without coding a custom API request.

You can also share data between applications using a message queue or message broker when one side lacks an API. Asynchronous data exchange can be enabled using systems like RabbitMQ, Apache Kafka, or Amazon SQS.

Making API-Less Integrations Reliable

Integration Challenges and Solutions

Whichever method you choose, the challenges compound at scale: authentication that breaks, schemas that shift, and monitoring that has to catch failures before they cascade. Encrypt data in transit, monitor integration activity, and be ready to adapt as source systems change — the specifics depend on which approach above you’re using.

Error Handling in API-Less Integrations

Error handling matters more for API-less integrations than for standard ones, because there's no consistent error format to catch. If you build DIY file transfers, you own incomplete transfers, corrupted files, and mismatched formats — which means logging, monitoring, and alerting for every hop. Direct database paths add their own failure modes: invalid SQL, schema drift, and type mismatches between systems.

That DIY burden is exactly what Deck is built to remove for portal workflows. Instead of maintaining selector-based scripts that fail when a page changes, Deck’s self-healing agents adapt to UI updates automatically. Each task returns schema-validated structured JSON through the Deck API, so you are not writing custom parsers for every portal failure mode. Retries and session teardown are part of the run lifecycle, which keeps transient auth and navigation errors from turning into silent data gaps.

Security Considerations for API-Less Integrations

Security matters most in API-less integrations, because you're often handling credentials the source system was never designed to share. DIY paths put the burden on you: lock down SQL permissions for database access, encrypt files in transit and at rest for SFTP, and isolate any UI automation you run yourself.

With Deck, those controls are the default for portal access rather than a checklist you assemble. Credentials are managed through encrypted storage, each session runs in an isolated environment, and agents only operate on portals the user has explicitly authorized. Sessions are torn down after each run with no shared state between them — the same model described in the FAQ below.

Best Practices for API-Less Integrations

What looks like “best practice” advice for API-less work is largely what Deck already does by default for authenticated portals: pick the access method that matches the source, keep data quality high with structured outputs, and avoid building a custom connector per system.

In practice that means integrating once through the Deck API, letting Deck handle login flows and MFA across portals, and receiving consistent JSON instead of maintaining a fleet of scrapers. Save DIY database, file, email, or queue paths for the narrow cases where you control the source and only need batch exchange — and use Deck when the source is a login-gated portal that will never expose an API.

When Does This Approach Make Sense?

You need to access a system that doesn’t have an API — utility, insurance, government, legacy enterprise.

• You’ve already tried building your own automation and it keeps breaking.
• You need to support many different portals and can’t maintain custom code for each one.
• Your product involves user-permissioned access to their own accounts.
• You need bidirectional access — not just reading data, but also submitting actions.

How Deck Solves This

Most teams hit the same wall: they need data from a system that was never built to share it. Building custom automation works until the UI changes, authentication breaks, or the next portal gets added to the list. At some point the maintenance cost outweighs the value.

Consider a property management company that needs to pull billing data from seven different utility providers, each with its own login flow and portal layout. Instead of maintaining seven separate scripts, they connect through Deck. The agent handles authentication for each portal, extracts the relevant records, and returns structured JSON through the Deck API. When one portal updates its UI, Deck adapts automatically. No script to fix, no downtime.

If your integration roadmap includes systems that will never have an API, that’s exactly what Deck is built for.

FAQ

How do you connect to software that has no API?

There are several approaches: direct database connections, screen scraping, file transfers, and browser-native automation. For production use cases involving login-protected portals, legacy systems, and applications that change frequently, browser-native automation through a platform like Deck is the most reliable option — it handles authentication, session management, and UI changes automatically, and returns structured JSON through a single API.

What is the best way to automate a portal with no API?

Deck is purpose-built for this. It manages login flows, MFA, CAPTCHA, and session handling for over 100,000 portals, and returns structured data without requiring a custom script for each one. When the portal’s UI changes, Deck adapts automatically, eliminating the maintenance burden that makes custom screen scraping unsustainable at scale.

What is the difference between screen scraping and Deck?

Screen scraping tools like Selenium, Puppeteer, and Playwright require custom scripts tied to specific UI selectors. When a website changes, the script breaks and needs to be fixed manually. Deck uses computer use agents that understand interfaces visually — they adapt to UI changes automatically, handle authentication natively, and work across any portal without per-portal scripting.

Is it secure to automate login-protected portals?

Yes, when done on infrastructure built for it. Deck manages credentials through encrypted storage, runs each session in an isolated environment, and operates only on portals the user has explicitly authorized. Sessions are torn down after each run with no shared state between them.

What systems does Deck support?

Deck supports over 100,000 portals out of the box, including legacy ERP systems, utility providers, insurance carriers, government databases, and financial institutions — any system accessible through a web interface, regardless of whether it exposes an API.