@verius My idea in this regard is this:

1] Custard makes a TCP connection with the pA API authentication endpoint
2] This endpoint verifies if the authentication is correct, if it isn't, it breaks at this point and sends an auth error
3] If the authentication information checks out, the pA API endpoint sends a communication of what features the server is configured to support  WILL POST_POLLS, WONT POST_EVENTS, whatever, with the authentication succeeded return code
4] The Custard client receives this and sends in return the features the client wants from the server  DONT SEND_POLLS, DONT POST_EVENTS
5] This information is saved in the session info for the client

Exceptional cases:

The client doesn't receive this additional info:
- We can probably safely assume its a GS or GS compatible instance in this case

The client fails auth:
- Simple standard HTTP response code for failed auth

The client wants something the server has disabled:
- Put it off