Choose your own app adventure

You may have already read about the Zendesk Apps framework (ZAF) and how you can use it to modify and extend your agent's interface in a number of ways.

But are you aware of all the paths that you can choose when starting your custom code adventure? Know the benefits of each approach, so you can determine what direction is best.

These approaches outline the main ways you can interact with the Zendesk Development Platform. Read from beginning to end, or jump to the area of interest -- each one has a short description along with links to more information.

Client-side apps

A client-side app is your custom code packaged up and deployed to all your agents. The app code runs in your agent's browser.

Zendesk stores your app's assets and serves them up to your agent's browser -- no need to host any of your app's assets on some other server. All your HTML, CSS, and JavaScript is bundled up and deployed by Zendesk. While you can reference external resources in your code, the main sources can all be bundled together in one package.

The app's manifest file (a JSON file that tells ZAF about your app at a high level) is the key.

In the manifest file, you tell ZAF about your app's starting HTML page using the location or url property -- if you specify an HTML file, it's a client-side app.

Sample client-side app manifest:

...
  "location": {
    "support": {
      "ticket_sidebar": "assets/iframe.html"
    }
  },
  ...

See how the manifest references "assets/iframe.html"? Because this is a local resource that isn't served up from a remote server, it makes this app a client-side app.

The manifest file and the iframe.html file are created when using zcli apps:new.

iframe.html is a generated name, but you can rename it to whatever you want. This html file is what's initially loaded and is the starting point for your app.

Related topics

• App framework manifest file reference
• Client-side app tutorial
• Developer guide - Apps framework

Server-side apps

The difference between "client-side app" and "server-side app" is where the assets of your app are located and who stores and manages them (Zendesk, for client-side apps; you, for server-side apps). Server-side apps still let you write custom code and deploy it to all your agents BUT it's now up to you to manage this remote server and the assets that it's serving to your agent's browser.

Along with determining where assets live, server-side apps can push more involved code away from the browser and into an infrastructure you control, made up of technologies that you choose.

In both cases, the app is still downloaded to your agent's browser and displayed there.

Sample server-side app manifest:

...
  "location": {
    "support": {
      "ticket_sidebar": "https://myserver.example.com/myappendpoint"
    }
  },
 ...

See how it references https://myserver.example.com/myappendpoint? Specifying a remote location is what makes it a server-side app. ZAF calls this remote endpoint once and loads whatever is returned by it into an iframe on your agent's desktop.

The upside of a server-side app is that it puts you in complete control of what's served up -- if you have changes you want to push to everyone, you update what the server request returns and all agents get the latest and greatest immediately -- no need to package up and upload a new version of your app. Some app developers use nothing but a remote URL for all their app locations.

The downside of a server-side app is that you are now responsible for maintaining your app's remote endpoint and all the operational concerns that go with it.

Related topics

• Apps framework manifest file reference
• Server-side app tutorial
• Securing your server-side app

Do you even need an app with a user interface?

The Apps framework lets you drop in custom code into your agent's browser for them to see and interact with. Maybe the app just displays information, maybe it manipulates the information on the screen before saving a ticket, maybe it does things the product cannot currently do -- such as the Zendesk Support's Out-of-Office app.

Apps are a great way to deploy custom functionality.

But do you always need an app to do something custom? You saw this coming -- the answer is 'No'.

The Zendesk development platform has an amazing set of APIs that let you do a lot outside the confines of the Apps framework.

Breaking out of the browser

Consider asking if your custom code should even be in the form of an app. If there's no need for direct agent interaction, consider putting your custom functionality on a back-end web server and have it authenticate into your Zendesk instance and call Zendesk APIs from there.

This might be a great option if, for example, you want to do incremental exports of your Zendesk data on a periodic basis and serve it up to other back-end services that you own. You wouldn't want a browser installed "App framework" app for that. You can instead incorporate it into a (possibly already existing) web server on your favorite hosting service and have it call into Zendesk directly, without relying on agent interaction.

Using just the API and scripts

An alternative of going with a web hosted solution is setting up a local script in the language of your choice and call the Zendesk API directly from there. Set up the script on a timed/cron job and you now have your automated solution.

Regardless if it's a local script running or something from a web server, it's up to you if you're calling the Zendesk REST APIs directly or using one of the language specific client libraries that conveniently wrap API calls.

Related topics

• API quickstart
• Common tasks for the Zendesk Support API
• Client libraries -- basically language specific convenience wrappers around the Zendesk API

Marketing apps

So-called "Marketing apps" (or "Integration apps") are publicly available integrations with Zendesk and do not have an actual app associated with them.

Marketing "apps" are displayed alongside other apps in the Zendesk Marketplace but don't actually get served up to an agent's interface -- they are third-party hosted services that integrate with Zendesk via API calls versus through a client- or server-side app. This integration between Slack and Zendesk is one example -- all processing is done on a back-end server, so there is no actual app that the agent sees.

Related topics

• App framework manifest file reference -- Marketing only apps
• Submitting integration apps

Channel framework

Channel framework integrations are special -- they don't get served up like other apps. If you're not already sure if this option is for you, chances are it's not (just sayin').

This functionality is for when you need to monitor, pull, and respond to customer comments posted on a third-party site -- such as Facebook or X (formerly Twitter). These are just examples -- Zendesk already natively supports these integrations.

While chances of needing to write a new integration with such a third-party social/reviews site are low, this framework exists to help you do that.

Related topics

• Developer guide - Channel framework
• Channel framework overview

Widgets

Widgets aren't "Apps framework apps" -- but are similar in that they can be customized and add a lot of value to your site. They are bits of embedded code that add extremely useful Zendesk features (live chats, knowledge base search, ticket submission) right on your own web pages. Widgets are very cool and you really should read up on them.

Related topics

• Using Web Widget to embed customer service into in your website
• Embedding Zendesk into your product
• Advanced customization of your Web Widget
• Web Widget API

Mobile app SDKs

If you're building mobile apps and you want to embed things such as Zendesk knowledge base lookup, creating and reviewing submitted tickets, and Chat right in your mobile iOS or Android app, then you need our mobile SDKs.

Related topics

• Embedding customer service in mobile apps with the Support SDK
• Developer guide - Mobile SDKs

Other things to know

Publishing your app

The Zendesk Marketplace is public and lets you expose your app's goodness to the masses. While a published app can be offered for free (and there are lots of those), there are revenue generating options as well.

Related topics

• Publishing your app in the Zendesk Marketplace
• Getting a trial or sponsored account for development

Global OAuth

If you're developing a public app that uses a service that requires accessing your customer's Zendesk resources, there's a good chance you'll want to use OAuth to authenticate into their Zendesk instances.

OAuth authentication can be tricky -- one of the things needed is you have to set up a Zendesk OAuth Client -- but how do you get all your potential customers to create an OAuth client correctly? That's where "Global OAuth" comes in -- it lets you create a single OAuth client that can be used by all your customers but still ensures security and separation between individual Zendesk instances.

Related topics

• Do I need a global OAuth client?
• Am I ready for a more advanced authentication option?
• Adding third-party OAuth to a Support app

Community

Despite the many resources mentioned above, working out problems with peers in a larger community can be a lot more efficient and rewarding. The Zendesk Support community is a great resource to find and share information. There are specific areas focused on development with long-time users and moderators of the development platform sharing tips and tricks.

It is actively monitored by both Zendesk & community moderators, but the real value comes about when more community members share with each other -- so check it out!

Related topics

• Zendesk Apps framework (ZAF) community
• Zendesk APIs community
• Zendesk SDKs community