Creating a Private App
Apps built for private use can take many forms. Some examples may include:
An organization purchases multiple seats for employees and creates an app for internal use
A developer automates sending surveys and/or exporting survey data for an SM account or Team
A team creates functionality to send thank you emails when their survey is completed
Private apps have different guidelines than apps publicly available in the App Directory. Here are a few key differences:
|Private Apps||Public Apps|
|Eligible for the App Directory||No||Yes|
|SurveyMonkey account needed by Developer||Sign In to View Plan||Any|
|Plan needed to utilize app functionality||Sign In to View Plan||SurveyMonkey account needs to be an enduser of the app|
|Who purchases user’s SM accounts||Developer||End User|
|How many accounts can access the app||One SurveyMonkey account or one Team||Unlimited|
|API call limits*||500/day, more available (Contact sales)||Unlimited|
|Requires approval before launching||No||Yes|
Think your app is better suited to be Public? Check out Creating a Public App.
*Please see our API Developer Terms for more guidelines when building with our API.
Building a Private App
- Here’s a sample guide for creating an end-to-end customer feedback app using the SurveyMonkey API:
- After authorizing into a SurveyMonkey account, the user chooses from a list of existing surveys, a SurveyMonkey template, or creates a new survey.
- If the survey results need to correspond to an existing object (e.g. product, customer, support case), the developer can automatically add a custom variable to the survey.
- An app can then grab a weblink and send a survey through either their own email tool, or use SurveyMonkey’s email system.
- Response data is stored in SurveyMonkey, and automatically returned via the API to the partner in real time (using webhooks).
Tips for reducing your API call usage
Use webhooks instead of polling. Besides providing added stability, webhooks reduce the number of calls needed to be made on the client side by only calling the API when there’s new activity (rather than on a regular basis).
Caching on the client side. We see lots of apps continually requesting details for the same resource from the API. If the resource isn’t going to change, cache it, and use webhooks to signal a refresh, if available.
Queue up your changes. Bundle incremental updates to resources together, if they don’t need to be sent over immediately.
Use the Bulk API endpoints. Where applicable and available (survey details, responses, recipients, contacts), try making bulk calls.