So I'm planning to use APIs for my host app. But the APIs are built such that it requires a sessionkey for every request.

So my question is, how would I dogfood my API? Cause, apparently I'm thinking in the line of creating a "special" key for my host app (cause it makes no sense to request for a key for my own use), but, anyone inspecting the headers of the request could find this key and literally use it and bypass requesting their own keys.

Maybe there's a best practice for dogfooding our own API without a special key or someway to differentiate whether the request is coming from the host app or the public.

I couldn't use IP to differentiate too, cause the public could be using the same server to call the APIs. That's just the way it is, and is a one of the constraints to keep in mind.

  • 9
    "cause it makes no sense to request for a key for my own use" - why?
    – ckhan
    Apr 29, 2013 at 9:21
  • @ckhan, MetaFight cause using the host app, you're already logged in and authenticated, so there's no reason to request a sessionkey just to use the APIs.
    – resting
    May 1, 2013 at 5:04

3 Answers 3


You're about to learn an important lesson about APIs. Any time you find yourself saying "I need something special that shouldn't be available to others", you're wrong. That's especially true when it comes to identification and authentication.

  • and also especially true when talking about testing. Test what the users will use, not some special code only you have access to. Jul 24, 2013 at 1:04

There shouldn't be any special key on a live API server as you also mentioned that the header may be parsed and key may be found. What we did in a similar situation was creating a sandbox or a separate environment (separate URL only known to the development team) and then changing the code to accept a special key.

I think the point in the question is to skip authentication. To avoid sniffing secure communication is the solution i.e. communicating over HTTPS

  • Wouldn't this be susceptible to the same kind of communication sniffing as the original suggestion? If, in the original scenario, the special key could be discovered by sniffing, then, in the second scenario, the special key AND the sandbox can be found by sniffing. It sounds like proper authentication is needed.
    – MetaFight
    Apr 29, 2013 at 9:45
  • I thick the point in the question is to skip authentication. To avoid sniffing secure communication is the solution i.e. communicating over HTTPS. Apr 29, 2013 at 9:53
  • As Ross Patterson has already mentioned, "skipping authentication" is tantamount do "doing it wrong." And, what you're suggesting with HTTPS is a form of authentication. It's just delegated to somewhere else in the stack.
    – MetaFight
    Apr 29, 2013 at 13:29
  • @MetaFight Okay, I agree that skipping authentication is wrong, but that's the requirement in the question. Question is not "is it right or wrong?" it is "how...". Other than that HTTPS provides authentication of the web site and associated web server and not API authentication, it's also transport layer encryption which prevents Man in the middle attacks. link Apr 29, 2013 at 13:43
  • Regarding HTTPS you're absolutely right. It wouldn't hide either the special key or the sandbox url from the client. It would only prevent a man-in-the-middle from finding either. Fiddler is your friend and your foe ;)
    – MetaFight
    Apr 29, 2013 at 14:02

You have some choice, none of them special.

  • session based auth system

  • auth with each request

For a replacement of username and password,
you can choose or combine some methods like:

  • auth with digital credential like SSH keys

  • one-time auth like RSA tokens, SMS, PHONE CALL or some bio-methods

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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