Build for ALL of Your Users: A Deep Dive Into Designing User-Centric APIs

APIs form the backbone of modern digital products, enabling seamless communication between services and powering countless applications we rely on daily. Yet, despite their critical importance, I’ve often noticed a recurring issue: many APIs aren’t designed with the end users in mind. This disconnect frequently leads to frustrating experiences—not only for developers but ultimately for the users of the products built on those APIs.

At Apidays New York 2025, I had the chance to share my thoughts on this very challenge. Drawing from my years working in developer relations, community building, and API design, I wanted to highlight why so many APIs miss the mark—and how we can build better by thinking beyond just our immediate customers to include the users they serve.

Introducing Myself: Why This Perspective Matters

Before delving into the technical aspects of API design, I like to start on a personal note—often introducing myself through my dog, Asher. This small detail reflects a core belief of mine: technology should serve people, not the other way around. My journey spans from grassroots community building as a teenager to roles at companies like Digital Asset, Wix, and now LibLab, where I help automate transforming APIs into SDKs from OpenAPI specs.

This work gives me a unique vantage point. I’ve observed that APIs designed with genuine user understanding tend to be more robust, easier to adopt, and more successful commercially.

The API Pet Peeve: When APIs Ignore Their Users

One frustration I encounter repeatedly is APIs that feel rushed or incomplete. Often, the main product is well thought out, but the API—sometimes a secondary interface—gets treated as an afterthought. This results in APIs that expose raw backend data without considering how developers and end users will interact with them.

A common example is APIs that simply mirror their database schema. While this may speed up internal development, it burdens API consumers with complex workflows and multiple calls just to assemble the data they actually need.

This isn’t hypothetical—it’s a real pain point that impacts developer productivity, customer satisfaction, and even a company’s bottom line.

The Importance of Understanding “Users’ Users”

At Wix, I saw this issue play out in real life. Our customers were developers building websites, but those websites had visitors—users of users. These downstream users are equally important in API design because the ultimate success of any product depends on their experience.

At LibLab, every client I work with builds products for other people. This layered user relationship adds complexity but also opportunity: APIs should serve not only direct customers but the entire chain of users.

A Realistic Scenario: Designing a Real-Time Chat API

To make this concrete, I often walk through a hypothetical SaaS real-time chat service example. The service uses WebSockets for live chat and a RESTful API for other functions. The API follows REST principles, uses proper HTTP verbs, and has clear endpoints.

Consider two API areas: user profile data (including photos) and chat group membership. The API exposes user profiles reflecting the backend database structure, with a foreign key linking profile photos stored separately. Similarly, the chat group endpoint reflects the data model closely.

Building Success, Then Hitting Walls

Imagine a customer builds a wildly popular group chat app on this API, handling tens of millions of messages monthly. But when asked to add profile photos, the API’s simplicity becomes a barrier.

There’s no direct URL for photos in the user profile—just a photo ID. Developers must make an additional call to a separate endpoint to get the photo URL, which points to an S3 bucket.

Hidden Complexities in Photo Handling

This design introduces several issues:

• Unclear URL stability: The API docs don’t clarify whether S3 URLs change when photos update, leaving developers unsure how to handle caching.

• No versioning in URLs: The URLs lack version or timestamp info, which complicates cache invalidation strategies.

• Non-constructible URLs: The URLs seem random, with no relation to user IDs, preventing URL construction from existing data.

While it’s possible to implement this for a single user, scaling this approach becomes a headache.

Scaling Challenges: From One to Many

When the app needs to show photos for all 256 members of a chat group—and potentially more—the naive approach leads to hundreds of API calls per user join. This can balloon to hundreds of requests to the chat service and S3, creating significant inefficiencies.

The Ripple Effect: Engineering, UX, and Costs

This design impacts several areas:

• Engineering complexity: Developers face building complex workflows, parallelizing calls, and managing caches.

• User experience: Slow loads and errors frustrate users.

• Cost: Even cheap calls add up at scale, driving unexpected expenses.

Faced with these challenges, teams might explore batch requests, request API improvements, reduce group sizes, implement parallelization, add caching layers, or even consider alternate APIs.

The Key Lesson: Build for All Your Users

This scenario highlights a fundamental truth: APIs must be designed for the entire user ecosystem, not just direct customers. The usability of your API directly shapes the products built on it and the experiences of downstream users.

Architect APIs with Intent

To avoid these pitfalls, I advocate for:

• Going beyond REST basics: REST principles matter, but your API must reflect real user workflows and market needs.

• Aligning data and API design: Don’t simply mirror your database—design APIs that serve user-friendly, efficient access patterns.

• Cross-team collaboration: Engage product, sales, and marketing teams who understand customer segments.

• Iterate and version: APIs evolve as you learn user needs and workflows—embrace continuous improvement.

Remember Your Customers’ Customers

Your customers have users, and understanding their needs shapes better API decisions. Consider their workflows, data patterns, and performance expectations to create APIs that simplify everyone’s life.

Keep AI Integration in Mind

With AI and natural language interfaces gaining ground, API usability becomes even more critical. At LibLab, we support the Model Context Protocol, which enables AI systems to interact smoothly with APIs.

Simple, intuitive API endpoints enhance experiences for large language models and other AI tools, making your API future-proof and opening new possibilities.

Practical Recommendations for API Teams

To build better APIs, I recommend:

1. Ask your users: Regularly gather feedback—informally or via surveys—to understand pain points.

2. Conduct user interviews: Dig deeper to uncover the “why” behind challenges.

3. Dogfood your API: Use your own API extensively to spot rough edges, but balance this with external feedback.

4. Build sample apps: Provide realistic demos that help developers learn and succeed.

5. Offer SDKs: Encapsulate complex workflows in SDKs to improve the developer experience and gather insights.

6. Leverage specs and tools: Use OpenAPI and governance platforms to standardize and automate API workflows.

Conclusion: Designing for a Connected Ecosystem

APIs aren’t just technical interfaces—they’re bridges connecting multiple layers of users and experiences. Designing successful APIs requires understanding everyone in that chain, architecting thoughtfully, collaborating broadly, and staying user-focused.

In today’s fast-changing digital and AI-driven world, this approach is essential, not just best practice.

For those interested, LibLab provides tools to simplify transforming APIs into SDKs and improve usability. Embracing these principles now prepares your APIs to meet tomorrow’s connected challenges head-on.