1. Have a goal
Communicate the objectives and goals you want the participants to achieve clearly and without room of interpretation. Tell them your criteria to judge if the the goal has been reached. That will enable the participants to think in the right direction and it will help you to easily find the winning team. Whether its to try out your API or to construct some fascinating algorithm - write it down and stick to it. BTW, also tell them about the prices as well :-)
2. Know the technology
You really have to be knowledgeable about your technology. And: you must be able to explain it to the participants. Tell them which technology to use, how to use it and what bugs and issues are known. They don't have to try it all out for themselves - that will only lead to frustration - and time is short. You really have to know your ropes concerning APIs, protocols, data models and frameworks. Be prepared to answer questions, so better think before, which might come up.
3. Built a protoype
There is nothing better to prepare for a Hackathon as to do everything you expect from the participants yourself in advance. Of course, you might not be as fast as they're gonna be, and you might not have a UI so pretty - but hack some code and try it all out, because only then will you really understand the relevant challenges with the technology. An then, if your prototype is ready, bring it and use it for reference.
4. Keep it simple
Time is running twice as fast as normal at a Hackathon. Or maybe even faster. So, nobody will find it amusing to read through handbooks to understand you challenge. So, keep it straight and simple. Remember, people are there to have fun and hack away freely. If possible only make them use ONE API not many, and only ONE protocol or data format. Use JSON and REST, instead of XML and SOAP. If possible leave out authentication. And avoid any extra overhead like having them deploy every hour or having them use a unknown tool.
5. Write documentation with sample code
You should write documentation for everything you want the participants to use, that will keep them from asking you everytime, The documentation should be proof-read to be as error-free as possible. It really has to be, so stay focused to keep if correct. And insert code snippets into the documentation which can be copy-pasted into their code and which should run out-of-the-box. Beware, some programs have problems with copying to the clipboard, like some acrobat versions, which distort the characters.
6. Bring all the stuff
You should not turn up there empty-handied, but rather carry a real large bag. You should bring a lot of marketing material, like banners, stand-up figures, mugs, T-shirts, stickers and everything a developer might love. Also bring all technology you might depend on, like projectors, adapters, notebooks and presentation software. If you need your laptop with the old VGA output, bringt the corresponding adapter.
7. Plan time before and after the event
Your technology and all relevant documentation should be up and running latest one week before the show. The participants just need some time to prepare themselves. And then, after the event let it all stay up and running for at least a week as well, because thedevelopers like to show off and tell their friends and collegues about it.
8. Dont show up there in a suit
And a tie is no good either. But bring a sleeping bag.
9. Collect the results
Be prepared to gather everything they produced at the event. You will need some time for that and better before the final presentation. So there should be dedicated people going around to collect all stuff. Perhaps you need a repository for that. And if you cannot get the code or the running system, then let them provide at least screenshots and/or movies - and their contact data.
10. Know your data
I experienced, that most teams show up at the Hackathon with a firm idea of what to build already in mind. And for this idea, they might need a certain dataset. So, if you cannot tell them how your data is structured and what the limits are, they won't have a good time. Be prepared to alter the dat if necessary or even to import extra data at the event.