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	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*	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

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).

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.