Device-to-API Scalable Architecture Best-Practices?

I’m having trouble finding concrete best-practices for architecture designs for mobile-to-API communication with a focus on scalable backend architecture. The common wisdom is to limit the number of HTTP requests the device makes as much as possible.

The basic scenario I’m dealing with is: say you want to submit a HTTP POST to create a record in the database, but that backend process is more complex than a simple single-row insert. Maybe it involves permission checks on the user, maybe there are multiple database requests that need to take place, maybe it needs to hit up other data stores, send notifications, etc.

At some point, it’s best to put that entire backend process (or as much that makes sense) behind a message queue and have it processed asynchronously.

But what does the device do if that happens? Doesn’t the device still need the primary id of the record it intended to create to store in its cache so the user can keep doing things? How does it receive that id if the creation process is asynchronously done? And what’s the best practice for receiving it? Tracking the request and polling for a result would violate the common wisdom of limiting the number of HTTP requests as much as possible.

If folks have ideas, articles or videos I haven’t been able to find that advise on this, I’d really appreciate it. Thanks!