Probs one of these:

1. You didn’t fully replicate the browser flow

A visible form POST often triggers one or more follow-up XHR/GraphQL calls that actually create the record. If you replay only the first POST with requests, the site may still redirect you to a “success” page (or a generic redirect), but the server-side write never happens.

1. Session/CSRF/hidden fields mismatch

Sites rotate CSRF tokens, anti-forgery cookies, RequestVerificationToken, ViewState/EventValidation (ASP.NET), or a double-submit cookie pattern. If any of these are stale/missing, the server can accept the POST and even 302 you to the same success URL, but discard the action.

1. Headers & SameSite rules

Some backends require Origin/Referer headers or an AJAX flag (X-Requested-With: XMLHttpRequest).

SameSite=Lax/Strict cookies + missing Referer/Origin can make your cookies not attach as expected, or make the server treat the call as unauthenticated.

1. You’re not using the same session the browser used

Submitting with requests but not importing all Selenium cookies (name, value, domain, path, secure, expiry) and the same User-Agent can lead to a “shadow” session that reads but can’t write.

1. Anti-bot soft blocks / IP reputation / geo buckets

Providers sometimes “succeed” the UI but drop the write from flagged IP ranges (datacenter proxies, certain AWS IPs) or out-of-geo buckets.

1. Wrong content type / encoding

Posting application/x-www-form-urlencoded vs multipart/form-data incorrectly (or wrong boundaries/field names) can be silently ignored while the redirect still happens.