Bracketed query parameters must be correctly encoded to avoid malformed requests or ignored values in REST Message callsIssue When making outbound REST calls from ServiceNow to an API that uses bracketed query parameters (e.g., filter[limit]=10 or page[number]=2), customers may find that their requests do not produce expected results. This includes scenarios where the API ignores the provided parameters, always returns default results (e.g., page 1), or returns a 404 despite a valid endpoint and authentication.ReleaseNot release specific.CauseThis behavior is known to occur when the entire query string is manually encoded as one literal string (including equals signs = and ampersands &) and inserted directly into the request, such as using a variable substitution. This results in the receiving API treating the entire query string as a single malformed parameter. For example: filter%5Blimit%5D%3D10%26page%5Bnumber%5D%3D2 This is interpreted as one parameter: filter[limit]=10&page[number]=2 Instead of being parsed as two parameters: filter[limit]=10 and page[number]=2. As a result, APIs may ignore the pagination or filtering logic entirely, return default data (such as page 1), or reject the request depending on how strict their parameter parser is.ResolutionOnly the reserved characters (like square brackets) should be percent-encoded, and the query string should remain structurally intact as multiple key-value pairs. When constructing REST Message calls in ServiceNow: Use the Query Parameters related list on the REST Message to define each parameter individually: Name: filter[limit], Value: 10Name: page[number], Value: 2 Or, if using a dynamic string or substitution variable, ensure the query string is encoded correctly: filter%5Blimit%5D=10&page%5Bnumber%5D=2 The API will now be able to interpret these as two separate parameters: filter[limit]=10 and page[number]=2, preserving the intended logic for filtering or pagination.Related LinksRFC 3986 – Reserved CharactersRequest Headers and Query Parameters