While each app is different in terms of what data it requires and what level of API access it needs, all apps run from an iframe on our app server.
Access to your Zendesk data
When installing an app in your Zendesk instance, any app automatically gains access to your data via the Zendesk App Framework it needs via the user permissions of the person using Zendesk. Most SweetHawk apps also require access to the server side API because they can interact with your Zendesk when you are not necessarily logged in such as to send reminders. Access to the server side API needs to be explicitly granted and you will be prompted for this when required.
Note that when granting SweetHawk access to the server side API, you are not providing access to data not available via the app framework already, you are only granting access for the SweetHawk app server outside of the app framework.
This process of granting API access is very straight forward. The first time you use the app upon installing an app that requires server side API access, follow the prompts to enable it. This must be done by an admin because to initialize the apps securely we need server side access to modify the app's internal settings with a secure token.
The provisioning process takes place on our secure app server. The first time an app is initialized, we create your account on the server. This account is assigned a unique token which identifies your account. This token is never shared with anyone and is required to access the data associated with your app. Once you authorize our server to access your data via API, we can then store this token with your app. This happens behind the scenes on the server side over a secure connection only.
Why do apps need server side API access?
Each is app is subtly different. But the apps only read or write data where you would reasonably expect this. The main reasons the apps need server side access are:
* Calendar: setting ticket fields and at the time of the event start and end, tagging the ticket. Also for sending notifications when other users update a calendar event.
* Tasks: setting fields on tickets, such as how many tasks are completed and what the parent ticket ID is.
* Due Time: tagging a ticket at the due date/time and sending an in-app notification.
* Deadline: updates a ticket with a special tag when the deadline hits.
* Approvals: loads ticket data to send messages to approvers, tags tickets if required, sets a custom field called Approval Date when all approvals are granted, and creates targets for automatic approvals.
* Survey: sets a value for the secure token Zendesk user field and creates Dynamic Content for the new customer satisfaction snippet for use in notifications.
* Brand Manager: updates notifications in targets and automations.
* Notify: to allow for quick editing of triggers and to send the notifications.
* Timers: to tag your ticket when a timer ends
For the Reminders app, access to the API is not required for the app to function, it only needs to be enabled if in-app notifications for agents are desired.
The apps RightGIF, Hide Ticket Fields and Undo do not require access to the REST API.
Data transfer and security
All data is encrypted using TLS 1.2 when transferred and this includes the app iframes that display the app UI inside Zendesk app locations, any data transferred to and from Zendesk APIs but also any external services such as Google Calendar.
Data storage and retention
To create the best experience in the apps, at times we mirror some data from Zendesk when app functionality is used, for example, we download and store ticket data when: a due time is set, a calendar item is created, or tasks are added. The reason the data is stored is for the purpose of caching, performance and to keep the rate of API calls to your Zendesk as low as possible. We also store credentials that are needed for example for external integrations. This information is kept securely on our server.
The Survey app is different from the other apps in that it does not store any personally identifiable information of your customers. read more
Expired cache data is cleaned up at times but there is no set policy for this.
Apps will download and retain minimal contact information about the person who installed the app so they may be contacted about app updates and important messages about potential issues. You may unsubscribe from app updates at any time.
Server technology stack
We use a PostgreSQL database server running on a server only accessible from our multi-tenanted Ruby on Rails application server, with a replication slave.
Our policy is to keep Operating Systems, web server software and application libraries up to date on the latest security patch versions.
Do I have access to my data?
If you wish to obtain your data please contact us and we will kindly oblige.
I'm no longer using your app, can you delete my data?
Of course, just contact us and we'll dispose of your data responsibly.
I use an IP whitelist for my API access, what are your IP addresses?
You must add all our server's IP addresses:
126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11
Note: using an IP whitelist is not recommended as our IP addresses change from time to time and this will stop the apps from functioning correctly. To be notified when our IP addresses change, please add yourself to this mailing list.