Explaination of the Problem:

Per the IETF URI Templating Spec the following characters are considered 'general delimiters', 'reserved delimiters', or 'sub delimiters':

  • ":"
  • "/"
  • "?"
  • "#"
  • "["
  • "]"
  • "@"
  • ","
  • "|"
  • "&"
  • "!"
  • "="
  • "$"
  • "'"
  • "("
  • ")"
  • "*"
  • "+"
  • ";"

Because these characters are considered delimiters, they signal a break in the data. Standard variable expressions (ex. "{email_address}") are designed, per the spec, to not cross delimiters. As such, if one of the previously listed characters is found in the variable space, the API Manager will assume that the client is specifying a break in the data and will start trying to match the remainder of the URL. For example:

A URL Template defined as:


Will fail to match the following request:


As {email_address} will only contain 'test'.

The Fix:

Per the URI Template Spec, you can specify that you want a variable to capture 'general delimiters' by adding a '+' to the beginning of the variable name. For example:

The URI Template:


Will successfully match the request:


As {email_address} will successfully capture the '@' delimiter. 

Note: The current version of the Try-It feature in the API store doesn't know how to properly handle the "+" identifier. The Try-It feature will not work properly with these paths, but any other tool (curl, postman, etc) will work just fine as will normal API calls. This will be fixed when we update to the latest version.

Another option is available if you know that a special character will always be present in the variable. You can specify the special characters in the template outside of the variables. For example, if you have a comma delimited key like:


The following template will match the request:


Please note that this template will only match paths that include a comma. If your path may only include special characters occasionally then the above solution is preferred.