#api#integration#finance

Integration without an API: how to connect a system with no ready-made connector

What to do if a service has no ready-made connector: API, files, queues, CLI, RPA/browser gateway, and MCP. Risks, security, and monitoring.

  • In short: start from the contract and move to the fallback, not the other way around
  • Diagram: integration reliability ladder
  • Why "no API" does not mean "integration is impossible"
  • What options remain

Diagram: integration reliability ladder

From a supported contract to a controlled fallback

Official contract

API / webhookdocumentation, limits, scopes, SLA
Marketplace connectorsupported entry point

Scheduled exchange

CSV / XML / XLSXexport, import, SFTP, email
Scheduled jobssustainable for back-office flows

Adapter

CLI / SDKnarrow command, JSON output, tests
MCP / servicepermissions, auditing, reuse

Fallback

DevTools Networkportal behavior analysis
Browser automationrare operations, strong monitoring
The lower the level, the fewer guarantees the vendor provides and the more governance your team needs.

Why "no API" does not mean "integration is impossible"

In a real B2B landscape, there is often no neat ready-made connector:

  • legacy portal
  • incomplete API
  • closed banking client
  • industry portal
  • CIS marketplace
  • CRM with outdated documentation

That does not mean the process must remain manual forever

But that means the integration cannot be designed as "the agent will log in and do everything itself."

You need to choose the most stable available contract, isolate it with an adapter, and define in advance where the system can fail.

What options remain

Official API or webhook

First checkpoint: documentation, pricing, limits, scopes, sandbox, changelog, and terms of use. Even an incomplete API covers basic operations better than UI behavior.

Files and scheduled exchanges

CSV, XLSX, XML, SFTP, email notifications, and schedules often look boring, but they provide a sustainable back-office setup where real-time is not needed.

CLI or SDK

A thin command with flags and JSON output suits an agent well: the model calls a limited tool rather than getting arbitrary access to the shell or portal.

MCP or internal service

If the integration is needed by many agents and teams, it needs a governed contract: permissions, auditing, rate limiting, retries, data masking, and a stable tool description.

DevTools Network

Useful for analyzing which requests the portal makes. But an internal endpoint can change without warning and is not required to be an approved integration method.

Browser automation

Playwright or an RPA approach is appropriate as a fallback for rare operations, reconciliations, migrations, and back-office scenarios. It is a poor foundation for a high-load SLA.

How to choose an approach

  1. 01

    Describe action

    What we read or change, how often, which data is affected, and who owns the business process.

  2. 02

    Check the contract

    Look for API, webhook, export, import, SFTP, reports, SDK, CLI, and contractual constraints. It is cheaper than supporting someone else's UI.

  3. 03

    Assess risk

    Money, personal data, legally significant actions, bulk changes, and customer notifications require human approval and a separate log.

  4. 04

    Isolate the adapter

    The external system should not leak into the core ERP, CRM, or PIM. The adapter normalizes data, errors, and retries.

  5. 05

    Set up monitoring

    Health checks, alerts, trace/HAR without secrets, error screenshots, and a fallback process are needed before production, not after the first failure.

DevTools Network is a source of understanding, not an official API

  1. The Network tab in Chrome DevTools shows which requests the page sends: URL, payload, headers, cookies, statuses, and latency.

  2. This is useful for research: to understand pagination, data format, CSRF, rate limits, and the action sequence.

  3. But repeating such requests in production is only possible after reviewing the service terms, contract, and security.

  4. Internal endpoints are not a public contract: they can be renamed, shut down, restricted by IP, or tied to a new session.

  5. That is why the correct wording is not "we found a hidden API"

  6. , and "we found a fragile research layer that requires separate governance."

CLI and MCP: different levels of the same adapter

For a narrow, repeatable operation, CLI is often enough: `orders export --from 2026-07-01 --format json`, machine-readable output, tests, and clear errors. The agent invokes such a tool only when needed, and secrets and permissions remain outside the prompt. CLI-Anything and similar approaches help build agent-native interfaces faster, especially around existing code, but the production wrapper still requires manual review, tests, and an access policy.

MCP is needed later: when the same adapter is used by different agents, you need discovery, unified permissions, an audit trail, and a stable tools contract. More about this layer on the pages MCP and AI-native integrations.

Browser automation: the last fallback

Browser automation is appropriate when there are no other options and the business process still needs to be removed from manual work: reconcile a report, transfer a reference list, fetch a rare export, or perform a migration. But browser automation is more expensive than API integration: it requires stable selectors, session management, MFA procedures, cookie protection, error tracing, concurrency limits, and readiness for UI changes. In critical financial and legal scenarios, a headless browser must not click "confirm" without separate approval.

Assess where AI can deliver impact in your process

clients@kt.team Telegram @kt_team_it

When the approach is sustainable and when it smells like a hack

Sustainable

  • there is an official API, export, or contractual exchange channel;
  • the adapter has tests, logs, retries, idempotency, and monitoring;
  • the model calls a limited tool instead of receiving tokens, cookies, and an arbitrary browser.

Risky

  • the integration relies on an unofficial endpoint without legal/security review;
  • a rerun can create duplicate orders, payments, requests, or statuses;
  • there is no fallback process for the day the portal UI changes.

Governance checklist before launch

Permissions and secrets

Separate service accounts, minimal scopes, tokens outside the repository, cookies, and MFA secrets do not end up in the prompt, logs, or agent artifacts.

Tool boundary

The agent invokes approved commands/tools. No arbitrary shell, browser, or employee-like access without an accountability model.

Idempotency

A rerun must not duplicate documents, payments, statuses, submissions, or customer notifications.

Observability

Action logs, correlation IDs, health checks, alerts, traces without secrets, and clear diagnostics for rate limits, bans, UI changes, or network errors.

Human approval

Payments, deletions, publications, bulk changes, and legally significant actions are confirmed by a human or a separate approval process.

Fallback

The business has a procedure for when the portal changes, the endpoint disappears, the IP is blocked, or the service adds an extra check.

CIS network boundary

A separate practical problem is the network. The model may require foreign outbound access or a corporate proxy, while a CIS service may accept requests only from the CIS segment or from an IP allowlist. This cannot be solved with a prompt. You need separate processes and environments: one route for reaching the model, another for the CLI, MCP server, Playwright, or local adapter.

In Claude Code, this is designed through environment settings, proxy variables, allowlists, and wrapper scripts; it is important that the team can see which traffic goes where and which secrets are available to each process.

When it is better not to integrate

Sometimes the honest answer is not to build automation. If the service explicitly forbids the required access method, the operation is critical for money or legal compliance, the UI changes every week, the volume is high, and the vendor provides neither API, export, nor a contractual channel, integration through the portal may cost more than the manual process. In those cases, it is better to change the process, negotiate with the vendor, buy a supported connector, or move the data into a system where the business has a proper contract.

Cases

KT.Team integration cases

All integration cases

Integrations

We will help connect a closed system without a brittle hack

We will review the available channels, choose the least risky contract, and build an adapter with tests, logs, permissions, monitoring, and a fallback process.

  • audit of API, file exchanges, the portal, and the network boundary
  • CLI, MCP, or a service adapter based on repeatability and risk
  • governance: secrets, permissions, audit, idempotency, human approval
Discuss integration

Bottom line: build an adapter, not a dependency on someone else's UI

Integration without a ready-made connector is possible, but a mature approach does not start with "let's look at Network and replay the request."

First, look for a supported contract.

Then we check scheduled exchanges.

Then we build a CLI, service adapter, or MCP

And only if there are no other options do we use browser automation as a controlled fallback.

The fewer guarantees the vendor provides, the more responsibilities your team has:

  • authority
  • logs
  • limits
  • monitoring
  • legal review
  • manual recovery plan

Sources

Verification date: 09.07.2026

Discuss the article: Integration Without API: How to Connect...

Send via:

By clicking the button, you accept the offer and grant consent to the processing of personal data.

Related solutions

All solutions
How to build a queue-based REST API for site-to-1C exchangeAI SDK 6: a unified TypeScript layer for models and MCPManagement reporting automationWeb services and API integration development

Articles on the topic

All articles

Related videos

All videos
5:14 Integration via REST API | Fewer errors and faster processes 5:14 API architecture and service brokers | Effective integrations 4:24 API Integration Methods / Which Integration Fits Your Business?

News on the topic

All news