FAQ
From ePrize Developers Wiki
This is a list of Frequently Asked Questions about using ePrize Web Services.
What's the bare minimum I need to know?
ePrize Web Services is a set of RESTful service calls designed to provide application developers with straightforward access to ePrize promotion back end services. The services provide promotion functionality such as profile registration, login, awarding of a game play, playing a game, awarding sweepstakes entries, and are designed to be seamlessly integrated into your online campaign.
What is BReWS?
BReWS is Engineering's name for ePrize Web Services. It stands for Better RESTful ePrize Web Services. Now that that's covered, we'll be using BReWS for the rest of the FAQ.
How do I get started?
The absolute shortest path: Call ePrize at 1(877) 837-7493 or email us at questions@eprize.com to get an API key. Access your service at http://code.eprize.com/v1/{apikey}/.
How do I talk to the experts?
We are the experts, and we are all subscribed to our BReWS mailing list. Read about that here: Webservices Mailing List
Does BReWS provide the logic that determines if a consumer should earn an award, like a sweepstakes entry or game play?
The client is responsible to determine when the user should get the sweeps entry or game play. It is ePrize's logic that will determine whether or not the user is a winner.
How does BReWS handle Invalid Email Format, Address Not Verified, and Too Young to Play?
We will send back a validation error for Invalid Email or Invalid Age. Address Not Verified will not be sent back to the client because it allows people to test how our system handles fraudulent entries. Any address that does not pass verfication is marked ineligible behind the scenes.
How does BReWS handle Already registered or Already played today?
When someone is Already registered and tries to register again, a duplicate registration error will be generated. It is the client's responsibility to log people in if they have already registered. (This is not built-in to the API because it makes the API less flexible.) The API will not send back Already played today, but the client can look at the history of awarded plays and see when a person has played.
Can I use CAPTCHA with BReWS?
Yes. See: CAPTCHA
Can you do rewarded and unrewarded Tell a Friend emails?
Yes, clients can incentivize how ever they want. A promotion could award an extra game play on Tell a Friend, or when answering a survey, or winning a high score. The options are limited more by law than by the API.
How do I access my promotion data?
Full access to promotion data is handled through Client Portal. The API will have a limited set of calls available for accessing promotion metrics data.
How do I know who wins a game?
Game plays that win will result in an immediate message back to you that the game play was a winner. You turn that into the messaging and creative you want to show your lucky winner. BReWS has no copy, images, or prize names.
Does BReWS choose Sweepstakes Winners?
Yes, it automatically selects sweepstakes winners based on the sweepstakes awarding schedule submitted at API Key creation.
Can I run multiple promotions off the same registration base?
You can choose to use one API Key for all profile storage, then separate API Keys for all the promotion games. If it's important to differentiate one promotion from another based on anything other than registration date, the client must include a promotion name when registering someone for a promotion.
If I have to store my own data, what's the value of BReWS to me?
You only need to be responsible for your website text and creative, not individual profile data or game information. All the logic of profile validation, storage, security, and game play happens on ePrize's secure systems. This allows you to focus on what's important, be that low-cost mass-production of a simple promotion template, or wildly complex integrations with existing web sites.
How can ePrize store all the data if I have to decide when game plays are awarded? Isn't that inconsistent?
You always decide when game plays are awarded and ePrize always decides who wins. In deciding to award plays, the client can ask ePrize for a consumer's profile, or use information from their own computers. For example, if the client built a typical microsite with a login page, the consumer would enter her email on the login, then the microsite would ask ePrize if the email was already registered. If it was registered, the client's microsite could make decisions using what's contained in the profile. If the email wasn't registered, the microsite would show the registration page. This is just one simple possibility. What if the microsite is embedded in a bigger web site with a shopping cart? The site doesn't display a login or registration page because it already asked for that stuff as part of the check-out flow. It automatically sent ePrize a registration using the shopper id instead of an email. Plays could be awarded based on what's in the shopping cart, what's in the profile, or any combination. The client's web site decides what plays should be awarded, then tells ePrize to award the plays.
