There's going to be at least two calls involved unless you use webhook-style authentication on a Apex REST API endpoint exposed to the public through a Force.com Site. With that style of authentication, you accept input from any caller in an unauthenticated session, and authenticate it through an HMAC with a pre-shared secret key. The running user for your Apex is the site guest user, rather than some integration or system user.
You lose some control here. You don't have a Connected App. You can't track inbound logins that way. Anybody on the Internet can poke your API - you have to code very, very defensively. I'm not an infosec expert but there's definitely implications to think through (how about a replay attack, for example?)
No matter which OAuth flow you use, or even if you decided to use a SOAP login()
call to get a Session Id, you'll have at some point to make a call to obtain a the session id (one call), plus making the actual call to your REST endpoint (two calls).
Personally, I would treat this more as a communication problem than a technical one. The web developer's intransigence doesn't really make sense to me on the face of it, and is going to push you to use a less-optimal architecture for, potentially, no good reason. I'd talk it through and find out why.