HTTP 409 Conflict: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, monitoring tool or integration receives an HTTP 409 Conflict response.
• A resource creation or update fails while other pages or API routes continue to work.
• The error may occur only with one HTTP method, such as POST, PUT or PATCH.
• Repeating the same request produces the same conflict, while a request for a different resource succeeds.
• The response body may identify an existing resource, stale version, duplicate value, state transition or application rule.
• DNS may still resolve and TLS may still succeed because the request reached an HTTP-speaking endpoint; those are separate checks.

Root causes, ordered by likelihood

1. A resource already exists or a unique value is duplicated. A create operation can conflict with an existing record, username, identifier, filename or other uniquely constrained value.
2. A concurrent or stale update. The resource may have changed since the client last read it, so the submitted version no longer matches the current state.
3. An invalid state transition. The application may reject an operation that is not allowed in the resource's current state, such as modifying a completed, archived or locked item.
4. Application or web-server rules. Route logic, validation, request policies or custom error handling may deliberately return 409 for a known conflict.
5. Proxy, CDN or WAF behavior. An intermediary can generate or transform the response because of routing, caching, request inspection or upstream configuration.
6. Environment-specific authentication or authorization rules. Some applications use 409 for a conflict involving account or resource state, although authentication failures more commonly use other status codes. Confirm the behavior from the response and logs rather than assuming the status code's source.

How to fix it

First, confirm the request

1. Record the exact URL, HTTP method, request body, authenticated user or client context, time and final status code.
2. Check the response headers and body for a conflict identifier, resource location, version information, cache status, proxy marker or application error message.
3. Confirm whether redirects occurred and whether the 409 came from the final endpoint or an intermediary.
4. Avoid changing configuration until you know whether the response is intentional for that route and method.

If you are a visitor or API consumer

1. Verify the URL, selected account or resource, and submitted data.
2. If the operation creates a resource, check whether it already exists before submitting it again.
3. If the operation updates a resource, refresh or retrieve the current version and retry only with the application's supported update workflow.
4. Sign in through the normal account flow if the resource requires authentication; do not submit passwords or tokens to an untrusted page.
5. Avoid repeated retries when the response indicates a duplicate, locked state or server-side limit.
6. If the conflict persists, send the site owner or API provider the endpoint, method, timestamp, response body and a sanitized request identifier. Remove passwords, cookies, API keys and personal data.

If you maintain the website or API

1. Reproduce the issue with the same method, URL, request data and account or client context. Use a test or staging environment when the operation changes data.
2. Determine which component generated the response: application, web server, reverse proxy, CDN or WAF. Compare response headers, server signatures and request identifiers where available.
3. Search the matching logs at that component and correlate the timestamp, route, method, user or client identifier and upstream response.
4. For create operations, check duplicate or unique-field constraints. For updates, check optimistic-locking, version, ETag or other concurrency data used by the application.
5. Review the resource's current state and the application's allowed state transitions. Do not bypass a conflict simply by deleting or overwriting data unless that action is authorized and understood.
6. Compare recent deployments and changes to routing, validation, authentication, caching, proxy and WAF rules.
7. Apply the narrowest documented correction, then retest the same request and a normal request for related routes. Confirm that the response body, headers and status code now match the intended behavior.
8. If the 409 is intentional, make the response actionable by explaining the conflict and, where appropriate, identifying how the client can refresh, choose a different value or resolve the state.

Prevention & how to verify the fix

• Document which operations can intentionally return 409 and what clients should do next.
• Use clear duplicate, stale-version and invalid-state messages in API responses.
• Test create, update and concurrent-update workflows after application releases.
• Keep routing, proxy, authentication, caching and WAF configuration version controlled.
• Monitor status codes by route and HTTP method rather than treating all 409 responses as one issue.
• Retain application and infrastructure logs long enough to correlate conflicts with deployments and configuration changes.
• Use a documented concurrency strategy, such as the version or conditional-update mechanism supported by the application.

Frequently asked questions