I can't connect to the Stormpath REST API. Is the server down?

If you are having trouble connecting to the API, please first check our status page.

Assuming there are no issues listed, try making a simple REST call using a tool like cURL to make sure it’s not an SDK or integration issue. For instance, you could request your tenant id:

curl -u $API_KEY_ID:$API_KEY_SECRET -H "Accept: application/json" https://api.stormpath.com/v1/tenants/current
If the Stormpath API is listed as "Operational" on status.stormpath.com, there may be an issue on your network. Please ensure your DNS server(s) honor Stormpath DNS's TTL of 5 minutes for api.stormpath.com. Some users have experienced connection problems to Stormpath if their DNS infrastructure ignores Stormpath's DNS TTL settings.

If you are using Java, this might be a Java-specific problem. Surprisingly, Java does not defer to the operating system for DNS TTL resolution like most other applications. If you are using Java, please refer to the following articles and update your System properties accordingly:

  1. http://aws.amazon.com/articles/4035
  2. http://stackoverflow.com/questions/1256556/any-way-to-make-java-honor-the-dns-caching-timeout-ttl

These settings need to be set before the JVM attempts to make any network connections. Most people set -Dsun.net.inetaddr.ttl=0 on the command line or in a shell script to guarantee this. You could also invoke java.security.Security.setProperty("networkaddress.cache.ttl", "0") (or java.lang.Security.setProperty for JDK 6 and earlier) in your application code, but note that this could be invoked after underlying frameworks or infrastructure code have already created socket connections, which is too late.

For example, if you had code in a .war file that called java.security.Security.setProperty (java.lang.Security.setProperty on JDK 6 and earlier) and deployed the .war to Tomcat, this wouldn't work: Tomcat uses the Java networking stack to initialize itself much earlier than your .war's code is executed.

In short, you have three options if JVM behavior is causing your network issues:

1) You can't set networkaddress.cache.ttl or networkaddress.cache.negative.ttl as System Properties by using the -D flag or calling System.setProperty because they are not System properties - they are Security properties.

So if you want to use a System property to trigger this behavior (so you can use the -D flag or call System.setProperty), you will want to set the following System property:


2) Call java.security.Security.setProperty("networkaddress.cache.ttl" , "0") in your application code (or java.lang.Security.setProperty for JDK6 and earlier). Again, you must guarantee this runs before anything attempts to use the networking stack.

3) Edit the $JRE_HOME/lib/security/java.security file and change the following properties:

networkaddress.cache.ttl = 0
networkaddress.cache.negative.ttl = 0

Pay attention to the security warnings in the comments surrounding those properties. Only do this if you are reasonably confident that you are not susceptible to DNS spoofing attacks.

If the connection issues persist, please don’t hesitate to let us know! We are happy to help debug, and in the case of an outage, your feedback is always appreciated.

Have more questions? Submit a request



Please sign in to leave a comment.