12

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.

Improve this question
8
  • 5
    Trust me, nothing good can come of trying to rely on this for anything, why are you looking to do this?
    – superfell
    Commented Jan 24, 2013 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
    Commented Jan 24, 2013 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
    Commented Jan 24, 2013 at 23:48
  • 1
    If you have stored credentials and are calling login, the loginResult will tell you if its sandbox.
    – superfell
    Commented Jan 25, 2013 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
    Commented Jan 28, 2013 at 2:06

4 Answers 4

Reset to default
11

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")
        )
Improve this answer
4

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.

Improve this answer
2
  • 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
    Commented Aug 28, 2013 at 19:34
  • 2
    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 ♦
    Commented Aug 28, 2013 at 20:49
0

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

Improve this answer
0

It sounds like in your case, you are asking the user for credentials at some point. Why not also ask for the environment type that they are looking to login to? (either Sandbox or Production/Developer)

Then, store the environment type along with credentials... This will allow for you to make a login() call to the correct identity server, which will return the correct instance url.

Improve this answer

You must log in to answer this question.

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