Private apps have different guidelines than apps publicly available in the App Directory. Here are a few key differences:
| 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* | | 500,000/day** |
Requires approval before launching | No | Yes |
**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.