API Basics for Non-Developers: What You Need to Know

Your tech team says “we will connect it via API” and you nod like you understand the implications. You roughly know it means two systems talking to each other. But what does that actually mean for cost, reliability, and what is possible? Here is API literacy for decision-makers.

What an API Actually Is

Start with the restaurant analogy, because it is genuinely useful. In a restaurant, the menu is a defined list of what you can order. You do not walk into the kitchen and make your own food. You make a request from the menu, the kitchen fulfils it, and the waiter brings you the result. An API is that menu. It defines exactly what requests an external system can make to another system, what format those requests must take, and what the response will look like.

When Xero and HubSpot share data, HubSpot is not reading Xero’s database directly. It is making requests to Xero’s API: “give me the invoice with reference INV-0042.” Xero’s API validates that HubSpot has permission to ask, processes the request, and returns the invoice data in a standardised format.

This matters to you because: every automation you build depends on the availability and quality of APIs between your tools. No API means no automation, or an expensive workaround. A poor-quality API means unreliable automation. Understanding APIs helps you evaluate tools before you buy them.

Why APIs Matter for Your Automation Plans

APIs are the prerequisite for almost every automation. When your team discusses connecting two systems, what they are actually discussing is whether the APIs of both systems support the specific data flows needed.

Several questions determine automation feasibility:

Does the tool have an API? Some tools simply do not offer API access, or offer it only on expensive enterprise tiers. If a tool lacks an API, automating data exchange with it requires screen-scraping or manual export/import, both of which are fragile and time-consuming.

What can the API actually do? An API might allow reading data but not writing it. It might expose some objects (contacts, for example) but not others (internal notes). The gap between “has an API” and “the API supports what we need” is real and common.

What are the rate limits? APIs impose limits on how many requests you can make per minute or per day. Exceed the limit and your requests are refused. For high-volume automations, rate limits can determine whether a use case is feasible on a given plan tier.

Questions to Ask About Any Tool’s API

Before buying a new business tool, if automation is part of your plan, work through these questions with the vendor:

Is there a public API? Available to all paying customers, not just enterprise tiers.

Is it documented? Well-documented APIs mean faster development and fewer surprises. Ask to see the documentation before committing.

What are the rate limits? Particularly for tools you plan to use in high-volume automations. Get specific numbers, not just “it is generous.”

What are the API pricing implications? Some tools charge separately for API calls beyond a threshold. Know this before building automation that makes thousands of calls per day.

Does it support webhooks? A webhook is when the tool proactively notifies your system when something happens, rather than requiring your system to check repeatedly. Webhooks make real-time automation possible. Without them, your automation either runs on a delay or polls the API constantly. Our webhooks guide covers this in detail.

What is the versioning policy? APIs change. When vendors release a new API version, they sometimes deprecate old versions. If your integration was built on version 1 and they retire it in favour of version 3, your automation breaks. Ask: how long do old versions remain supported after new versions are released?

Common API Limitations That Affect Business Decisions

Rate limits that cap scaling. If your automation needs to process 10,000 records per hour and the API limits you to 1,000 requests per hour, your use case is not feasible at that speed without architectural workarounds.

Read-only APIs. An API that lets you read data but not write it means you can pull information out but cannot push updates back. This halves the value of most integrations.

Poor documentation. Undocumented APIs require a developer to experiment to understand what the system actually does. This adds hours of exploration to every integration project and makes maintenance harder.

Breaking changes without warning. Some vendors update their APIs without notifying developers or giving time to migrate. This breaks integrations without warning. Check a vendor’s history of breaking changes before depending on their API for critical automations.

No sandbox environment. Good APIs offer a sandbox (test environment) where developers can build and test integrations without affecting real data. The absence of a sandbox means development must happen against production data, which is risky and inconvenient.

API Red Flags When Evaluating Vendors

These are signals that a tool will cause integration headaches:

API access is gated to the enterprise tier only. Vendors who restrict API access to their most expensive plans are making a deliberate choice to monetise integrations separately. Factor this into total cost of ownership.

Documentation is sparse or outdated. If the documentation was last updated two years ago, you cannot trust it reflects the current API behaviour. Your developer will spend time discovering rather than building.

No webhook support. For anything requiring real-time or near-real-time response, the absence of webhooks forces polling, which is slower, more expensive on API costs, and less responsive.

Community reports of frequent breaking changes. Check developer communities (Stack Overflow, GitHub issues, Slack communities) for reports of this vendor’s API breaking existing integrations. It is a strong predictor of future maintenance cost.

Vague answers to specific questions. If the vendor’s pre-sales team cannot answer “what are your API rate limits?” or “do you support webhooks?” that reflects either poor product knowledge or deliberate evasion of inconvenient answers.

Our advisory service includes tool evaluation as part of any automation scoping engagement. We assess the API quality of your candidate tools before you commit to a purchase that turns out to block your automation plans.

Need help evaluating your tool stack for API compatibility? Get in touch or see how this applies in practice with our CRM automation guide.