How do I know whether my software will even let AI connect to it?
Check six things before committing: whether a documented API exists, whether your specific plan includes it, the rate limits, whether historical data can be pulled or only new events, whether webhooks are available or you must poll, and whether the fields you care about are actually exposed. Plan-level gating and missing historical access are the two surprises that most often reshape a project after it starts.
Having an API is not the same as having access to it
Most modern business software has an API. That fact tells you less than it should. Access is frequently gated by subscription tier, by an application and approval process, or by a separate agreement. It is common for a company to discover mid-project that the integration requires a plan they are not on.
Find this out first. It is a phone call to your vendor's support line, and the answer changes the shape of everything downstream — which is why it belongs in the earliest stage of integration planning.
The six checks, in the order that matters
- Documented and public? Public docs mean a stable contract. Undocumented endpoints work until they silently stop.
- Included in your plan? Ask specifically, and ask whether limits differ by tier.
- Rate limits. A limit that is fine for nightly reporting may be far too low for near-real-time work across many locations.
- Historical access. Some APIs expose only recent data or only forward-looking events. If you need year-over-year comparison, confirm the backfill window early.
- Webhooks or polling. Webhooks give you seconds; polling gives you whatever your interval is, and costs API calls you may not have to spare.
- Field coverage. The endpoint may exist while the one field you actually need — the source, the campaign tag, the custom status — is not exposed.
Where the field coverage trap shows up
Field coverage is the check people skip, and it is the one that quietly ruins reporting. An API can return every job with complete financials and still not return the lead source, because that field is custom or lives in a different object. You do not find out until you try to build the report that joins them.
The way to avoid it is to write your target report first, list every field it requires, then verify each one against the API documentation before any code is written. For operational systems in particular, custom fields deserve individual confirmation.
When there is genuinely no API
Some older or niche systems offer nothing but a report screen. The realistic options are scheduled exports, a database-level connection if the software is self-hosted, or replacing the system. Screen scraping is technically possible and generally a bad foundation for anything a business depends on.
In that situation the honest recommendation is often to build around the closed system rather than through it, connecting the parts that are open and treating the closed one as a manual input until it is replaced. That is a legitimate architecture, and a better outcome than a fragile connection that breaks every time a page layout changes.
Topics: API · access · due diligence · technical requirements
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.