If Your Software Doesn't Have an API, You're Going to Struggle | Active Logic Insights

Maybe not today, but eventually.

In addition to running a custom software development company (Active Logic), my family runs a coffee shop and we use Square for POS. And over time, working with it has made something very clear to me:

Most software is still designed around how companies think users should work.

But increasingly, real work is happening outside the UI.

The Shift: From Clicking to Prompting

There are two types of work I do regularly:

1. Bulk operations

Yesterday, I updated a large number of menu items in about 15 minutes.

That same task used to take several hours in the UI.

Not because the UI is bad, but because it was never designed for that type of workflow. UIs are optimized for one-at-a-time interactions — click, fill, save, repeat. When you need to modify 200 items, that interaction pattern becomes the bottleneck.

Through an API and AI tools like Claude CLI, I can script or prompt those updates directly. No repetitive clicking. No manual errors. No afternoon lost to data entry.

2. Asking better questions

Sometimes I don’t want to navigate dashboards or predefined reports.

I want to ask a simple question:

What was my best selling drink over the last six months?

In most UIs, that requires digging through multiple reports, filtering by date range, exporting to a spreadsheet, and stitching together answers. The data exists — the software just doesn’t expose it the way you need it.

With an API plus AI tooling, that becomes a direct query. You describe what you want to know, the AI constructs the right API calls, and you get your answer in seconds.

The difference is not convenience. It is capability — the ability to ask questions the software vendor never anticipated.

The Real Limitation of UI-First Software

A UI has to generalize. It is built around:

• Common workflows
• Assumed user behavior
• Predefined reports
• Fixed interaction patterns

That works for most users most of the time.

But it breaks down when:

• You need custom workflows that cross multiple screens
• You want cross-system automation between tools that don’t natively integrate
• You need bulk operations on hundreds or thousands of records
• You want to explore your data in ways the vendor didn’t anticipate

An API removes those constraints. It gives you raw access to your data and operations, letting you compose workflows that the original software designers never imagined.

APIs Are No Longer Just for Developers

The biggest shift happening right now is this:

APIs are no longer just developer tools. They are becoming the primary interface for AI-driven workflows.

Tools like:

• Claude CLI
• Codex
• Custom internal agents

are not clicking buttons. They are calling endpoints.

If your product cannot be used programmatically, it cannot be fully leveraged in an AI-driven environment. And as more business operations move toward AI-assisted automation, the products without APIs will become increasingly difficult to integrate into modern workflows.

This isn’t a future problem. It’s happening now. Companies are already choosing software vendors partly based on API quality — because they know their AI strategy depends on it.

Integration Is No Longer Optional

None of us use just one tool. We use:

• POS systems
• Accounting software
• CRMs
• Inventory systems
• Analytics platforms

The real value comes from how these systems work together. Your CRM should know when a client’s invoice is overdue. Your inventory system should trigger purchase orders automatically. Your analytics should pull from every source, not just the ones with pre-built connectors.

A well-designed API makes that possible. A weak or incomplete API makes integration painful, brittle, or impossible — forcing you to rely on manual processes or expensive middleware.

What a Good API Actually Looks Like

Not all APIs are equal. If you want your software to be usable by both humans and AI systems, your API needs to go beyond basic CRUD.

1. Support Partial Updates (PATCH)

One of the biggest gaps I see in APIs is the lack of proper partial update support.

Instead of requiring full object replacement:

PUT /items/123
{
  "name": "Latte",
  "price": 4.50,
  "category": "Drinks",
  "inventory": 120
}

You should support targeted updates:

PATCH /items/123
{
  "price": 4.75
}

This matters enormously for AI-driven workflows. AI tools often operate incrementally — they don’t always have (or need) full object context. Without PATCH support, automations become fragile because they risk overwriting fields they didn’t intend to change.

2. Predictable, Consistent Schemas

AI tools rely heavily on structure. Your API should have:

• Consistent naming conventions (don’t mix camelCase and snake_case)
• Clear resource hierarchies
• Stable response formats that don’t change between versions
• Strong typing via JSON Schema or OpenAPI specification

Bad:

{
  "itemName": "Latte",
  "cost": "4.50"
}

Good:

{
  "name": "Latte",
  "price": 4.50
}

Small inconsistencies — a string where a number should be, an unexpected field name — create big problems for automation. When an AI tool can’t predict the shape of a response, it generates defensive code that’s harder to maintain.

3. Idempotency and Safe Retries

AI-driven systems will retry requests. Network failures happen. Timeouts happen. The AI might re-run a step if it’s unsure whether the first attempt succeeded.

Your API should support:

• Idempotent operations (same request produces same result)
• Safe retries without creating duplicate records
• Clear status codes that distinguish “already done” from “failed”

Example:

POST /orders
Idempotency-Key: abc-123

This prevents duplicate orders when systems retry — a critical concern for any enterprise workflow that involves financial transactions.

4. Clear Authentication and Token Management

AI tools need secure, programmatic access. That means:

• API keys or OAuth flows that can be provisioned without human intervention
• Scoped permissions (read-only vs. read-write, per-resource)
• Easy token rotation for security compliance
• Clear documentation of auth requirements

If authentication is hard to implement or requires manual steps, integrations won’t happen — or they’ll happen insecurely with shared credentials.

5. Workflow-Oriented Endpoints

Most APIs are too low-level. They expose database operations (create, read, update, delete) but don’t expose the business workflows those operations serve.

Instead of only exposing raw CRUD, consider higher-level endpoints:

POST /reports/best-selling-items
{
  "start_date": "2025-10-01",
  "end_date": "2026-03-31"
}

This aligns with how users and AI systems actually think. Nobody wants to “query the line_items table joined with orders filtered by date” — they want to know what’s selling. Workflow-oriented endpoints close that gap.

6. Documentation That Works for Humans and Machines

Documentation is not optional anymore. It needs to be:

• Clear and example-driven (show the request AND the response)
• Machine-readable (OpenAPI spec that AI tools can consume)
• Easy to navigate with a logical structure
• Focused on real workflows, not just endpoint listings

AI tools do not “figure things out.” They depend on well-structured, explicit documentation. An OpenAPI spec isn’t just nice to have — it’s the interface between your API and every AI system that will interact with it.

The Bigger Shift

This is not just about APIs. It is about how software is used.

We are moving toward a world where:

• Humans interact through UI
• Systems interact through APIs
• AI acts as the bridge between the two

If your software is not designed for that reality — if the only way to use it is through a browser UI — it becomes harder to use over time, not easier. Every new AI capability that your competitors adopt becomes an advantage you can’t match.

What You Should Do About It

If you’re building software — or choosing software — here’s the practical takeaway:

1. Audit your current tools. Which ones have APIs? Which APIs are actually usable (not just documented)?
2. Prioritize API quality in vendor selection. A great UI with no API is a dead end. A decent UI with a great API is infinitely extensible.
3. Design API-first for new systems. If you’re building custom software, the API should be designed before the UI, not after.
4. Invest in cloud infrastructure that supports API-first architecture — proper authentication, rate limiting, monitoring, and versioning.

A great UI makes your product usable. A great API makes your product adaptable.

And adaptability is what matters in an AI-driven world.