There is something I've been noticing as I've been working to integrate GameSpark with our game while also working with Steam. Sometimes, when trying to perform a Steam authentication request, I'll get a error back from GameSpark's servers saying that the Steam request timed-out.  

Is there anything I can do to minimize these timeouts? Or are they just a fact of life when it comes with trying to use Steam as a means authentication? 

It is happening fairly frequently. Though I don't have any hard numbers to back it up, I'd say about 50% of our login attempts using Steam are resulting in the timeout error. To give a little more context, in the function where we perform our GameSpark authentication we do the following:

1) We request an AuthSessionTicket from Steamworks.
2) We convert the AuthSessionTicket into a hex string
3)  We wait 1 second. It may seem arbitrary, but since we don't know what Steams AuthSessionTicket function involves, I wanted to wait to give it time to populate anything.
4) We then make the SteamConnectRequest

Hey we're getting the same thing!

Steam API is a bit wonky. They actually have a hidden 350ms anti-spam timeout.

GameSparks will currently sit for the full 30 seconds waiting for the POST to respond, then timeout the entire script.

To update, after further research, Steam does *not* have a anti-spam timeout. First signs seemed to point to Steam. However, after testing with POSTman (as raw as it gets), signs point to a GS issue.

Since there's no way to set timeouts, the entire script just fails for a minor call, like checking if they are using family share that may not necessarily be crucial. However, without timeouts, a non-critical HTTP call creates fatal errors with the rest of the script just randomly stopping due to a timeout.

A workaround would give us access to timeouts (which should absolutely be here, anyway, to appropriately deal with a timeout within the script instead of timing out the ENTIRE script with just "error:timeout"). It creates an entire array of awkward situations just because a single HTTP call returns. Even if it is an important call, we'd need a timeout because no HTTP call is ever going to take more than a few seconds: We'd have a chance to try 1 more time upon failure, or at least log details about the incident. Instead, the only details we really get is "timed out after 30s" when the timeouts simply don't happen in POSTman.

Oops, I meant to say -- Steam DOES have an anti-spam timeout if you don't use their partner API. However, using their partner API, there is no cooldown.

(Gah, sorry, no edit): Some api calls that ask for an IP address I found in deep research that ip6 addresses may be causing it to hang on Steam's side. I'm trying to see if there's a chance that Spark's get IP func has a chance to return ip6.

Even if that's the case, we're back to not having access to HTTP timeouts, a crucial element of HTTP calls: We have to rely on 3rd parties to be 100% perfect or risk a fatal, unhandled, minimally-logged error.

That's the only lead I have, so far. I don't know much about ip6 - I can update more in the future.