The weekly community challenge is live! One winner gets $100 cash

Share your take: What’s one thing you wish every API did better?

Drop your answer in this thread. Short and simple works, but feel free to expand if you’ve got a strong opinion.

Need ideas?

  • Documentation that actually helps
  • Clearer error messages
  • Smarter authentication
  • Consistent naming conventions
  • Better versioning

Prize: Winner gets $100 cash (via Visa gift card)
Deadline: Thursday, Oct 2 at 10am BST / 2:30pm IST
How to enter: Reply to this thread within the 24-hour window.

This contest is open worldwide to participants 18+. By entering, you grant Postman the right to feature your submission on our website, blog, and social channels. Winner announced Friday. Go! :rocket:

5 Likes

Contextual Error Messages That Actually Help Debug

Most APIs give you cryptic error codes like “400 Bad Request” or “Invalid parameters” without explaining which specific parameter is wrong, what format it expects, or how to fix it.

I wish every API included:

Which exact field caused the error
What format/value it was expecting
A working example of the correct request
Links to relevant docs for that specific endpoint
For example, instead of:

{"error": "Invalid request", "code": 400}

I want:

{
  "error": "Field 'email' is required but missing",
  "expected_format": "valid email address",
  "example": "[email protected]",
  "docs": "https://api.example.com/docs/users#email-validation"
}

This would cut debugging time from hours to minutes and reduce developer frustration significantly. Good error messages are like having a helpful colleague explain what went wrong - they save time, reduce support tickets, and make APIs actually enjoyable to work with.

3 Likes

Most APIs will just suddenly return 429 errors with no clarity about how many requests you have left, when your quota resets, if failed requests count and all

You just keep making request until you hit a wall, then you start guessing, or even have to contact support to find out your limits.
Good APIs should include headers like your limit, remaining quota, when it resets etc.

Instead of allowing developers discover it by breaking things in production, which is the worst possible way to learn about infrastructure constraints.
In other words, transparency is key.

1 Like

I wish every API had a clear description of its endpoint and their parameters. It will be easy for anyone to understand what they can be used for

1 Like

Clear separation of environments

Sandbox: https://sandbox.api.example.com  
Production: https://api.example.com

API should auto-flag if one accidentally send a prod key in sandbox/staging (or vice versa).

Presently, I have to troubleshoot and go through each API requests to then find out that the error is from using wrong key.

It was an oversight from my end but a little help will go a long way. Littéralement!

1 Like

Smarter Authentication

One thing I wish every API had is a smarter Authentication feature, especially for applications with premium plans or subscriptions.

A good example would be a unique API key that would belong to the user and would be hashed and stored on the user’s record in the database.

The user API key can be created during sign up and is linked to the user’s account via email or passkeys, such that everytime the user signs in or sends an API request, the key on his account is used to validate the request.

This way rather than sending multiple requests with a single API key, each user request has a different key. When users renew their subscription, they get X amount of tokens/requests only them can use, rather than a developer paying for X tokens/requests that multiple accounts would use.

In situations where the user’s account has been inactive, the API key is inactive until the user reactivates their account.

1 Like

Using 400 and 500 Level Error Status Codes Properly

A lot of APIs that do return instructive error messages will return a 200 OK status along with the error message, this is something I’ve seen even in enterprise-grade APIs. It’s very odd to see the API return the message “your auth token is invalid” while having a 200 or 201 status instead of the 401 HTTP status one who knows about HTTP status codes would expect.

Further to that, APIs should make sure to use the proper 400/500 level status code to match their error message. It’s also odd when the API has the 500 (internal server error) status when the message says “We are currently under maintenance, please try again later”, a message that should ideally come with a 503 (service unavailable) status code.

One final thing APIs should do to clearly explain errors is also include the HTTP status code and its meaning in a separate field, for the benefit of people who aren’t skilled with or aren’t able to use an API platform like Postman at the moment. For example, instead of

{
   "message": "The required request header productId is missing"
}

The message should be more like

{
   "status": "400 Bad Request",
   "message": "The required request header productId is missing",
   "timestamp": "2025-06-12T13:42:19"
}
1 Like

One thing I wish every API did better: Clear, actionable error handling.

Most APIs today still return vague or overly generic error messages (like 400 Bad Request or 500 Internal Server Error), which leaves developers guessing what went wrong. Imagine if every API error response included:

  1. A descriptive message (e.g., "The 'email' field must be a valid address, but 'xyz' was provided" instead of just "Bad Request").

  2. Error codes that are consistent and standardized across endpoints (E001 for validation error, E002 for auth issue, etc.), so developers can programmatically handle them.

  3. A “next steps” guide or troubleshooting link in the error payload to help solve the issue faster.

    {
      "error": "Invalid email format",
      "code": "E001",
      "details": "The provided email does not match RFC 5322 standards.",
      "docs": "https://api.example.com/docs/errors#E001"
    }
    
    

Why this matters:

  • It saves developers countless debugging hours.

  • It reduces friction in onboarding new users.

  • It elevates trust in the API provider because devs feel supported instead of stuck.

Bonus improvements that tie in:

  • Smarter authentication flows (e.g., refresh tokens and OAuth flows that are well explained in docs).

  • Versioning that doesn’t break existing integrations suddenly, with clear deprecation timelines.

  • Consistent naming conventions across endpoints (no mix of camelCase, snake_case, or pluralization mismatches).

If every API prioritized developer experience the way great products prioritize user experience, the ecosystem would move faster and be far more inclusive for both junior and senior developers.

Thanks for reading.


2 Likes

The one thing I wish every API did better is provide documentation that includes detailed, practical code examples for common use cases in multiple popular languages.

While most APIs have reference docs, they often lack sufficient, working samples that demonstrate how to achieve a common task (like proper authentication, paginating results, or handling specific non-standard errors) in a ready-to-use snippet for languages like Python, JavaScript, and cURL.

* Why it matters: Good examples drastically reduce the time spent jumping between the API documentation, language-specific SDK docs, and Stack Overflow, immediately boosting developer experience (DX) and speeding up integration. It’s the difference between understanding what a parameter does and knowing how to use it effectively in a real-world application.

1 Like

1. OAuth 2.0: Implement OAuth 2.0 or other industry-standard authentication protocols to provide secure and flexible authentication options.

2. API keys: Provide API keys or tokens that can be easily generated, managed, and revoked.

3. Role-based access control: Implement role-based access control to restrict access to sensitive data and functionality.

4. Clear documentation: Provide clear documentation on authentication and authorization, including examples and code snippets.

1 Like

My answer is…
We need an API Documentation Standard.

Not just better docs or clearer errors an actual protocol/standard that every API should follow. Here’s what it should enforce:

1. Consistent Response Structure (Non-Negotiable)

Every endpoint returns the same format, every time, something like this can work:

{
  "statusCode": 200,
  "message": "Clear, actionable message",
  "successful": true,
  "data": {...}
}

Success or failure, 200 or 404, the structure never changes. No more hunting through result, payload, response, output, or whatever creative field name someone decided on that day.

2. Intelligent Error Messages

Error responses should include an AI validation layer that analyzes the error context and provides enhanced, actionable guidance. If the raw API error is cryptic, the AI layer interprets it based on the endpoint’s specs and returns something developers can actually use to fix the issue.

3. Conversational API Agent

Every API collection should come with a link to an integrated AI agent that has complete understanding of all endpoints. You should be able to ask:

  • “Where do I start with this API?”

  • “How do I authenticate?”

  • “What does this endpoint need in the request body?”

  • “Which endpoint’s response feeds into this one as a parameter?”

The agent maps endpoint relationships, provides real examples, explains which fields are required vs optional, and clarifies the relevance of each parameter. Basically, you’re talking to the API instead of decoding documentation. This should be possible to put together with RAG

4. Consistent Naming Conventions for every endpoint in the collection

Whether it’s REST, GraphQL, or something else naming should be consistent across the entire collection. If you use userId in one endpoint, don’t switch to user_id or UserID in another. Another example would be getAllUsers for this and not switching to fetchAllOrders for another. Consistency is the keyword, API should be predictable and remain predictable.

5. Built In Support Channels

Valid contact information for support must be included in the documentation. Though honestly, if the standard is followed properly, you shouldn’t need to contact anyone.

APIs don’t need to do more. They need to be predictably structured, intelligently documented, and genuinely conversational. An API Documentation Standard makes APIs easier to adopt, faster to integrate, and less frustrating to debug.

We shouldn’t have to think too much about how someone decided to structure their responses. There should be a standard, and everyone should follow it.

1 Like

I wish every API returned error messages that actually help you fix the problem, not just state that there is one.

Picture this: you send a request after 30 minutes of carefully debugging, only to get back 400 Bad Request or Invalid input. You’re left guessing — was it a missing field? Wrong format? Typo? Nested object issue? It feels like solving a puzzle in the dark.

A well-designed API error should point you straight to the issue, like a good linter does in code. For example, instead of this:

{ "error": "Invalid parameters", "code": 400 }

You should get something like:

{
  "error": "Validation failed",
  "details": [
    {
      "field": "email",
      "issue": "Invalid format",
      "expected": "valid email address",
      "example": "[email protected]"
    },
    {
      "field": "age",
      "issue": "Missing required field"
    }
  ],
  "docs_url": "https://api.example.com/docs/users#validation"
}

This kind of structure tells you exactly where things broke, gives examples, and points you to the right docs — so you fix the issue in seconds instead of fumbling through trial and error.

It’s even better when errors follow the same format across every endpoint and are structured in a way that tools can reliably parse. That consistency turns debugging from a guessing game into a fast, almost effortless process.

In short: good error messages aren’t decoration — they’re part of the API’s UX. A clear, structured error can save hours, reduce support tickets, and make the difference between a delighted dev and a rage-quit at 2 AM.

2 Likes

One thing I wish every API did better: understand what I’m trying to do and guide me there, not just validate what I sent.

Most APIs are reactive — they tell you what’s wrong after you mess up. I want APIs that are proactive and recognize developer intent.

What this looks like:

When I send a malformed request, instead of just saying “invalid JSON,” the API could:

- Detect I’m trying to create a user, but sent `phone_number` instead of `phoneNumber`

- Suggest: “Did you mean `phoneNumber`? Here’s the correct format.

- Auto-correct common mistakes in sandbox mode with a warning

Real example:

Instead of:

{“error”: “Validation failed”, “code”: 422}

Give me:


{

“error”: “Field name mismatch detected”,

“your_field”: “phone_number”,

“expected_field”: “phoneNumber”,

“suggestion”: “Rename and retry”,

“auto_fix_available”: true,

“sandbox_mode”: “Request would succeed with corrected field name”

}

Why it matters:

This shifts APIs from being gatekeepers to being collaborative partners. It acknowledges that developers make typos, forget conventions, and often integrate under pressure. Intent recognition turns frustrating trial and error into guided success.

We have spell-check in text editors — why not “intent-check” in APIs? Life of an engineer would have been better, and by making use of AI, it would have been super great for the developers to get the intent as well in the response.

1 Like

Idempotency!

In a space where AI consumption is increasing every day, it’s never been more important to get idempotency right. For anyone who’s unfamiliar with the term, idempotency is a quality of an API to have the same outcome on a system regardless of how many times it has been called. Now, that doesn’t mean the same responses (hot take alert :fire: ), but it does mean the same effect on the data.

Since AI agents can get into retry storms fairly easily, giving them an idempotency field in tools or an idempotency header in HTTP requests is a must have - and it’s something I don’t see in APIs as much as I would like. If multiple requests/tool calls come in with the same idempotency key, the API can return the value from the first time that key was seen.

Things I wish I saw implemented more often with idempotency:

  • Store a hash of the incoming payload along with the key and error if the key comes in with a different payload (validates against unintentional duplicate keys)
  • Invalidate the idempotency keys after a certain amount of time (they should not live forever)

It’s an important quality of API writes that needs more love :blue_heart:

1 Like

I wish every API had standardized, human-friendly error responses with actionable guidance. Instead of vague codes like 400 or 500, APIs should provide structured details (error type, cause, suggested fix, and docs link). This would save developers countless hours of debugging and make integration much smoother

1 Like

I wish every API had proper validation built in.

Too often, APIs either accept bad inputs without warning or throw cryptic error codes that leave developers guessing. Instead, APIs should:

  • Enforce strong validation rules at the design stage.

  • Return clear, consistent, and actionable error messages (e.g., “field age must be a number between 1–120”).

  • Provide examples of valid and invalid requests/responses right in the docs and even in error payloads.

This way, developers don’t just know what went wrong — they immediately see how to fix it.

1 Like

I wish every API made authentication seamless instead of an obstacle course.

I have spent hours juggling tokens, OAuth flows, and inconsistent security patterns while using Public APIs before even making the first call. Authentication should be:

  • Secure by design

  • Developer-friendly with clear docs

Postman’s guided authentication already shows what good looks like, walking you through complex setups step by step, so you can focus on building rather than wrestling with credentials.

Example

1 Like

The Problem: The Dreaded Double-Charge :weary_face:

​We’ve all been there. You send a POST request to create a resource—say, processing a payment or creating a user—and the connection times out. Did the request succeed before the timeout? Is it safe to retry?

​Without idempotency, you can’t know for sure. Retrying the request could lead to duplicate charges, duplicate user accounts, or other critical data integrity issues. This forces every single API consumer to build complex and often error-prone logic on their end to prevent these accidents.

​The Solution: The Idempotency-Key Header

​The solution is elegant and already adopted by best-in-class APIs like Stripe. Every state-changing request (POST, PATCH, etc.) should accept an Idempotency-Key in the header.

​Here’s how it works:

  1. ​The client generates a unique key (like a UUID) for an operation.

  2. ​It sends this key in the Idempotency-Key header along with the request.

  3. ​If the server sees a request with a key it has already processed, it doesn’t execute the logic again. Instead, it simply returns the original result from the first successful request.

​This guarantees that an operation can be safely retried any number of times without creating duplicate side effects.

​Why It’s a Game-Changer

​Implementing idempotency shifts the responsibility of ensuring “exactly-once” execution from the many API consumers to the single API provider. This single feature elevates an API from being merely functional to being truly robust and production-ready. It demonstrates a deep understanding of the real-world network failures that developers face and builds trust by making the API resilient and predictable.

​While better docs and clearer error messages are vital for developer experience, built-in idempotency is foundational for building reliable software on top of an API.

1 Like

I wish more APIs were actually consistent - like, internally consistent with themselves.

You know how you’re using an API and one endpoint returns dates as Unix timestamps, another uses ISO 8601 strings, and a third uses some custom format? Or how pagination works completely differently across endpoints in the same API? Or some fields are snake_case while others are camelCase?

It makes you feel like you’re learning a new API every time you hit a different endpoint, even though it’s supposedly the same service. You can’t build reliable mental models or reusable code patterns because the rules keep changing.

The friction isn’t just annoying - it’s cognitively expensive. You’re constantly context-switching and second-guessing yourself. “Wait, does this endpoint use limit or per_page?” “Is this one zero-indexed or one-indexed?”

Consistency is one of those things that’s invisible when it’s done right, but it compounds into such a better developer experience. You learn the patterns once and they just… work everywhere.

1 Like

/errors Endpoint — Real-Time Transparency for Every API


The Problem

Every developer has faced this: integrations suddenly fail with cryptic 500s, undocumented 429s, or stale docs that don’t match reality. Debugging becomes trial-and-error, support tickets pile up, and trust in the API erodes.


The Idea

Introduce a simple /errors endpoint that every API exposes, delivering live, machine-readable error intelligence. Instead of combing through outdated docs or vague error codes, developers get real-time clarity.


How It Works

  1. API Endpoint
  • Expose /errors (or /status).
  • Returns structured JSON with:
    • error code → human meaning
    • severity level
    • fix-it guidance
    • deprecation flags
    • live incident URLs
  1. Client Adaptation
  • SDKs and tools instantly display contextual help:
    3.“429 Too Many Requests → Use exponential backoff. See X-Rate-Limit headers.”*
  • CI/CD pipelines link alerts directly to ongoing incident reports.
  • Dashboards always reflect current error definitions — no guesswork.
  1. Example Response
[
  {
    "code": "429",
    "meaning": "Too Many Requests",
    "tip": "Use exponential backoff. See X-Rate-Limit headers.",
    "deprecated": false
  },
  {
    "code": "500",
    "meaning": "Internal Server Error",
    "tip": "Retry; if persists, check incident_url",
    "incident_url": "https://status.example.com/incidents/567"
  }
]

Why It Matters

With /errors, debugging shifts from reactive firefighting to proactive problem-solving:

  • Faster Integration — Developers resolve issues in minutes, not days.
  • Reduced Support Load — Fewer “What does this error mean?” tickets.
  • Greater Trust — APIs become transparent, reliable, and developer-first.

It’s a tiny addition with an outsized impact: making APIs not just functional, but friendly.

1 Like