Right now the API uses an HTTP header to define which network to use, however it does not send a Vary header for systems to know that the response varies based on this header, or a Cache-Control header to indicate the response isn't cacheable in general.
A better approach, however, to using a header for this purpose is to make the network part of the request (and send the appropriate Cache-Control headers) (e.g., /api/v1/network/<networkAlias>/<networkSpecificRequest>) with the custom configuration being handled as a network alias of something like @custom and the parameters for it provided as a query string (e.g., customHost).
Right now the API uses an HTTP header to define which network to use, however it does not send a
Varyheader for systems to know that the response varies based on this header, or aCache-Controlheader to indicate the response isn't cacheable in general.A better approach, however, to using a header for this purpose is to make the network part of the request (and send the appropriate
Cache-Controlheaders) (e.g.,/api/v1/network/<networkAlias>/<networkSpecificRequest>) with the custom configuration being handled as a network alias of something like@customand the parameters for it provided as a query string (e.g.,customHost).