Does Your Software Have an API? A Quick Check Before AI

Most business software has some kind of API, but not every plan includes it, and not every API covers the task you want automated. The fastest way to find out is to place each tool into one of four access levels: a documented API, a scheduled export or import, browser-only access, or no machine access at all. Do this before you design an agent, because the answer decides what the agent can do reliably and what a person must keep doing.

Key takeaways

• An API is only useful if it covers the specific read and write actions your workflow needs, not just the product in general.
• Sort every tool into four levels: API, export or import, browser-only, or none. Then plan the agent's role around the weakest link.
• Check the plan, the permissions model and the terms of use, not only the documentation. An API can exist and still be unavailable to you.
• Exports and browser-only tools can still work, but they are slower and more fragile, so they need tighter limits and human review.
• A one-page access inventory takes an afternoon and prevents most surprises during integration.

What does it mean for software to have an API?

An API (application programming interface) is a documented way for one program to read or change data in another without a person clicking through screens. When a vendor says it has an API, that can mean very different things. Some APIs expose almost everything the product does. Others expose a thin slice, such as creating a contact but not updating one, or reading invoices but not their attachments.

For an AI agent, the question is narrower and more practical: can the agent perform the exact actions your workflow needs, with credentials you control, under limits you can audit? An API that lets you list customers but not create a quote does not help an agent that is supposed to prepare quotes.

There is also a difference between having an API and being allowed to use it. Vendors often gate API access behind a higher plan, an admin approval step or a separate agreement. The documentation may describe features your account cannot reach. So the check has two parts: what the API can do, and whether your account can use it.

The four access levels to sort every tool into

Put each tool in your business into one of these levels. The level tells you how much autonomy an agent can reasonably have with it.

• Level one, documented API: the vendor publishes endpoints, authentication and limits. An agent can read and, where permitted, write data directly. This is the most stable option.
• Level two, export and import: you can download data on a schedule (as a file or report) and upload changes through an import function. An agent can work from fresh copies and prepare changes, but not act in real time.
• Level three, browser-only: the only way in is the web interface. An agent can sometimes operate it through browser automation, but the result depends on screen layouts, logins and anti-automation rules.
• Level four, no machine access: the data lives in a person's head, on paper, in a desktop app with no export, or behind a login that forbids automation. The agent can only receive information handed to it by someone.

Most companies find a mix. The common pattern is that the main system of record has an API, the supporting tools offer exports, and one or two critical tools are browser-only. That mix is normal, and it is workable if you know it up front. The tradeoffs between direct integrations and screen-driven ones are covered in more depth in API vs browser automation for AI agents.

How to check one tool in about ten minutes

Repeat these steps for every tool involved in the workflow you are considering. Use one row per tool in a simple sheet.

• Step one: search the vendor's help center and developer pages for API, developer, integrations, webhooks and export. Note the page address of anything you find.
• Step two: confirm whether your current plan includes API access. If the documentation is unclear, ask the vendor in writing and record the answer.
• Step three: list the actions your workflow needs, such as find a record, read a field, create a draft, update a status. Mark which of them the documentation supports.
• Step four: check how authentication works. Look for named options such as API keys, OAuth or service accounts. If you are unsure which fits, see service accounts or OAuth tokens for AI agents.
• Step five: check whether you can limit what a credential can do. Read-only or narrowly scoped access is far better than an all-powerful admin login.
• Step six: look for exports. Find which reports or files can be downloaded, in which formats, and whether the export can run on a schedule.
• Step seven: read the terms of use for anything about automation, scraping or bots, especially for browser-only tools.
• Step eight: write the level (one to four) in the sheet, plus the name of the person who administers the tool.

If a tool takes much longer than ten minutes to assess, that is itself a finding. It usually means the integration will need more effort than it first appears.

What else should you ask besides whether an API exists?

A yes to the API question is the start of the check, not the end. These questions separate an API that works for an agent from one that merely exists.

• Does it support read and write, or read only? An agent that drafts and updates needs both.
• Can credentials be scoped to specific data or actions? This matters for the principle in least privilege for AI agents.
• Are there rate limits, and what happens when they are reached?
• Does the tool send events (webhooks) when something changes, or must the agent keep checking? The choice is explained in webhooks vs polling for AI workflows.
• Can the same request be sent twice without creating duplicates? If not, the agent needs its own safeguards.
• How do connections expire or get revoked, and who is notified when that happens?
• Is there a test or sandbox environment, or will every trial run touch live data?
• Does the API return clear errors, so a failed action is visible rather than silent?

Several of these answers shape what the agent is allowed to do on its own. A tool with only read access, for example, is a natural place for an agent to start. The same thinking applies to heavier systems, and connecting an AI agent to your ERP walks through what to check first when the system of record is large and old.

An illustrative scenario: a small distributor sorts its tools

This scenario is illustrative, not a real case. Imagine a small wholesale distributor that wants an agent to prepare order confirmations and chase late supplier replies. The operations lead builds the access sheet in one afternoon.

• The invoicing tool has a documented API on the current plan. Level one. It can be read and can create draft documents.
• The shared inbox allows delegated access with limited permissions. Level one, with care about what the agent may send.
• The stock list lives in a spreadsheet that a colleague updates by hand. Level two: it can be shared or exported, but it is only as current as the last edit.
• The main supplier uses a web portal for order status, with no export and terms that discourage automation. Level three, flagged for review.
• The delivery schedule is kept on a whiteboard in the warehouse and photographed each morning. Level four until someone enters it somewhere readable.

The result is useful. The agent can safely start with drafting confirmations from invoicing data and monitoring the inbox. The supplier portal stays a human task, with the agent preparing a short list of orders to check. The whiteboard becomes a small process fix: someone types the schedule into the spreadsheet each day. None of this required building anything yet, but it shaped what the first version of the agent should and should not attempt.

What if a tool is export-only or browser-only?

Export-only tools are often better than they look. A scheduled file gives the agent a stable snapshot to read, and a controlled import gives you a review point before changes land. The weak spot is freshness. If the agent answers from last night's export, it should say so, and your team should know which questions need live data. Spreadsheets are a common middle ground, and connecting an AI agent to spreadsheets without losing data covers how to keep that safe.

Browser-only tools need more caution. Browser automation depends on screen layouts that can change without notice, on logins that may expire, and on terms that may forbid it. If you use it, keep the task narrow, prefer read actions, require approval before anything is saved or submitted, and log what the agent did. Where the tool is critical and the risk is high, ask the vendor whether an API or export exists on a different plan, or consider whether the tool is the right one to keep.

For tools with no machine access at all, do not force it. Use a human step: a person pastes the needed information into a form or a chat, and the agent works from that. A reliable human handoff is a better design than a brittle workaround.

How does Be Human handle tool access checks?

Be Human starts a first engagement by defining one useful role for the agent, then builds the access inventory for the tools that role depends on. Each tool is classified by access level, the actions it must support are listed, and the credentials are scoped to the smallest set that works. Approval boundaries are set per action, so reading, drafting and sending are treated as separate permissions. As part of managed operations, Be Human monitors the connections, reviews permissions on a regular basis, maintains integrations when vendors change them, and handles incidents such as expired credentials. The company keeps control of which tools and actions the agent may use. Before go-live, the integration is checked against an acceptance checklist so that the access sheet matches what was actually built.

Frequently asked questions

Does my software have an API if I cannot find one in the help center? Possibly, but not necessarily one you can use. Check the vendor's developer pages, your plan details and the admin settings, and then ask support in writing. If the answer is no, look for exports or a partner integration before assuming the tool is closed.

Can an AI agent work with software that has no API? Yes, within limits. The agent can read exports, work from information a person provides, or operate the web interface under strict controls if the terms allow it. Expect more review and less autonomy than with a documented API.

Who should run this check in our company? The person who administers each tool is usually best placed to answer, with someone from operations collecting the results in one sheet. Involve IT or whoever manages accounts, because plan limits and credentials often sit with them. The whole inventory can be done in an afternoon for a typical set of tools.

Is a protocol like MCP a substitute for having an API? No. A protocol such as MCP gives an agent a standard way to discover and call tools, but a tool still needs something underneath it to talk to, usually an API or another controlled access path. Your access check tells you what that underlying path is, and what MCP is and why it matters for business agents explains where it fits.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.