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:
Criteria
Private Apps
Public Apps
Eligible for the App Directory
No
Yes
SurveyMonkey account needed by Developer
Any
Plan needed to utilize app functionality
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*
starting at 500 calls/day (contact sales)
500,000/day**
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.
**Limits are subject to change

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.