EDIT - I've updated title and added answer, there are issues using . in URLs for Salesforce REST

I am writing a REST web service in salesforce to return information about accounts. I am finding that when I use an email address in the URI, I get a Salesforce error.

Here's some code to show the problem

@RestResource(urlMapping = '/showaccount/*') 
global without sharing class showAccount {

    global static String doGet() {
        String uriRequested = RestContext.request.requestURI;
        return uriRequested;

If I go ahead and make a rest call to the following URL:


then the response is as expected, http code 200 and body of "/showaccount/this_sort_of_key_is_fine"

However if I call the URL and the last part looks like an email address, as follows

/services/apexrest/showaccount/[email protected]

then my rest code isn't executed by Salesforce and the response is http code 404 with a body of: [{ "errorCode": "NOT_FOUND", "message": "The requested resource does not exist" }]

The question how-does-salesforce-handle-wildcards-in-a-rest-urlmapping-property is interesting as it seems to me that my problem is also related to how Salesforce is finding the correct rest class from the supplied URL.

I have also found that if I change the urlmapping of the class to /showaccount/*/* then the class is successfully called when I use /showaccount/[email protected]/ (but note the trailing / which I would like to avoid).

So my question is

  1. is there a way to make this work so that I can use a call like /showaccount/[email address] and get a response?
  2. does this sound like a Salesforce bug?
  • 2
    For a REST API where I controlled both the client and the server, I used base 64 encoding to avoid this problem (as a pragmatic work-around for whichever part of the email address was causing the problem). But far from ideal for a public REST API.
    – Keith C
    Commented Jun 4, 2014 at 9:38
  • 1
    Sounds like an issue which should be raised with the SFDC team as that is a perfectly valid URL. I don't believe the client making the request should be forced to add the trailing slash or replace the . with %2E.
    – Mark Pond
    Commented Jun 4, 2014 at 17:08
  • Thanks @MarkPond, I agree. SFDC have said this is down to the regex they are currently using to map the URL to the resource. Hopefully this will be addressed in future.
    – Doug B
    Commented Jun 5, 2014 at 10:00

2 Answers 2


I have had a response from Salesforce support and I've also done a bit more experimenting. The problem comes from the . character not the @ and the word from salesforce was "using REST API .json and ,xml extension so there is a rule in load balancer that uses regex depending upon how many characters added after dot."

So the following examples are illustrative:

/services/apexrest/showaccount/bob@test          GOOD
/services/apexrest/showaccount/[email protected]    ALSO GOOD (the pieces after the . only 2 chars long)
/services/apexrest/showaccount/[email protected]      ERROR 404
/services/apexrest/showaccount/[email protected]/     GOOD

Looks like with the way that the regex is implemented you should be very careful if the URL can include the period character and terminate the URL with a / if possible


UPDATE: this answer is incorrect. Had considered deleting it, but it may still be usefull to indicate that this was not the problem.

Haven't actually tested this, but according to this question on stackoverflow , this RFC 2396 answer on stackoverflow and the W3schools article on URL Encoding I believe the @ character should be URL encoded, and that that is likely the cause of why Salesforce is mis-interpreting your http request.

  • 1
    Actually it's not the @ that causes it to choke, it's the period (.) So URLencoding doesn't work, if I use /showaccount/customer%40busy.com then I get the same error. However if I go to /showaccount/customer@busy%2Ecom Salesforce does find my resource. However it's not a standard encoding and I don't believe that this is correct REST behaviour. I would be forcing my clients to do a custom encoding which is not obvious.
    – Doug B
    Commented Jun 4, 2014 at 9:44
  • Thanks for the answer though Samuel :)
    – Doug B
    Commented Jun 4, 2014 at 9:54
  • 2
    W3schools should not be considered reliable. See w3fools.com. Quoting an RFC is definitely better.
    – sfdcfox
    Commented Jun 4, 2014 at 15:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .