Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Given a Salesforce Org Id, how can I determine the name and serverUrl to use with APIs?*

For example, given the Org Id 00DE00001234ooT I can get the Pod/Server identifier from the first character after the keyPrefix. In this case it is E, which I know is NA9.

There are some more details about the Pod identifier in the question What are Salesforce ID's composed of?

Why might this be useful? From the comments... If you have a Salesforce Username, Password and OrgId and want to establish a Salesforce Session it is useful to know if you are dealing with a Sandbox or Production/Dev org. You can use the Pod Id from the OrgId to determine if it is a Sandbox and then call the correct login URL (login.salesforce.com versus test.salesforce.com).

* this will not work correctly for orgs that were previously migrated to other instances as the OrgId will still reference the original pod.

share|improve this question
4  
Trust me, nothing good can come of trying to rely on this for anything, why are you looking to do this? –  superfell Jan 24 '13 at 23:31
    
@superfell Partially out of interest and partially because I'm lazy :) . I'll often use the SessionId and ServerURL to establish a Partner API connection in various tools, such as the Force.com Explorer WIL Emulation. If I can get away with just the SessionId in the majority of cases I can save myself another copy and paste keystroke. –  Daniel Ballinger Jan 24 '13 at 23:40
    
@superfell I did come up with one use case outside of developer tools and hacking. I have an external system that periodically establishes a Partner API session using stored credentials (with some robust encryption). If I have the OrgId I can figure out if I'm dealing with a Sandbox and create the Session accordingly. –  Daniel Ballinger Jan 24 '13 at 23:48
    
If you have stored credentials and are calling login, the loginResult will tell you if its sandbox. –  superfell Jan 25 '13 at 0:01
1  
@user31 I've done that in the past. Going straight to the correct login pool should save some time for a sandbox login. –  Daniel Ballinger Jan 28 '13 at 2:06
show 3 more comments

3 Answers

Do not do this. It will break the instant your org gets migrated to a different instance, and will not work if it has been in the past. You save yourself a few keystrokes now, but you (or your replacement) will endure hours of pain as they try to figure out why the migration broke the integration.

share|improve this answer
    
Yes, org migration and the addition of new pods are known issues with this approach. I did mention this in the question. I'll make it bold to better emphasis the risk. It does have its uses, but won't be the best approach in many cases. –  Daniel Ballinger Aug 28 '13 at 19:34
1  
But, you can use the answer that has the Pod prefixes to make a determination to call login or test. A production will never migrate to a sandbox server, nor will a sandbox server ever migrate to a production server. –  sfdcfox Aug 28 '13 at 20:49
add comment
up vote 1 down vote accepted

I found one possible solution in the source code for Workbench.

They maintain a mapping structure that includes the pod identifier:

"valuesToLabels" => array(
            "login" => array("Login: Production/Developer",""),
            "test"  => array("Login: Sandbox (test)",""),
            "prerellogin.pre" => array("Login: Pre-Release", ""),
            "na0-api" => array("NA0 (ssl)","0"),
            "na1-api" => array("NA1","3"),
            "na2-api" => array("NA2","4"),
            "na3-api" => array("NA3","5"),
            "na4-api" => array("NA4","6"),
            "na5-api" => array("NA5","7"),
            "na6-api" => array("NA6","8"),
            "na7-api" => array("NA7","A"),
            "na8-api" => array("NA8","C"),
            "na9-api" => array("NA9","E"),
            "na10-api" => array("NA10","F"),
            "na11-api" => array("NA11","G"),
            "na12-api" => array("NA12","U"),
            "na14-api" => array("NA14","d"),
            "ap0-api" => array("AP0 (ap)","1"),
            "ap1-api" => array("AP1","9"),
            "eu0-api" => array("EU0 (emea)","2"),
            "eu1-api" => array("EU1","D"),
            "eu2-api" => array("EU2","b"),
            "tapp0-api" => array("Sandbox: CS0 (tapp0)","T"),
            "cs1-api" => array("Sandbox: CS1","S"),
            "cs2-api" => array("Sandbox: CS2","R"),
            "cs3-api" => array("Sandbox: CS3","Q"),
            "cs4-api" => array("Sandbox: CS4","P"),
            "cs5-api" => array("Sandbox: CS5","O"),
            "cs6-api" => array("Sandbox: CS6","N"),
            "cs7-api" => array("Sandbox: CS7","M"),
            "cs8-api" => array("Sandbox: CS8","L"),
            "cs9-api" => array("Sandbox: CS9","K"),
            "cs10-api" => array("Sandbox: CS10","J"),
            "cs11-api" => array("Sandbox: CS11","Z"),
            "cs12-api" => array("Sandbox: CS12","V"),
            "cs13-api" => array("Sandbox: CS13","W"),
            "cs14-api" => array("Sandbox: CS14","c"),
            "cs15-api" => array("Sandbox: CS15","e"),
            "cs16-api" => array("Sandbox: CS16","f"),
            "cs17-api" => array("Sandbox: CS17","g"),
            "prerelna1.pre" => array("Pre-Release: NA1","t")
        )
share|improve this answer
add comment

This isn't great, but the pod identifier comes back as part of an OAuth2 handshake...

&instance_url=https://cs14.salesforce.com

One needs a UserId and an endpoint in addition to the OrgId though :P

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.