Platform and Developer

Hi Zendesk Community & Guide Developers,We are customizing our Zendesk Guide Help Center theme (style.css and script.js) to display video tutorials and embedded media catalogs inside knowledge base articles.While the responsive layout works well on desktop viewports, we are running into a layout constraint on mobile devices:1. Iframe Height Clipping: Embedded HTML5/HLS video containers inside article templates do not scale dynamically, creating double vertical scrollbars on iOS Safari and mobile Chrome.2. DOM Sanitization: The Guide article editor strips certain custom inline styles and allowfullscreen attributes upon saving unless explicitly wrapped inside specific container classes.Is there a recommended CSS aspect-ratio wrapper snippet or JS event listener for Zendesk Guide script.js that dynamically adjusts iframe container heights across mobile viewports without triggering the built-in HTML sanitizer?Appreciate any technical guidance from Zendesk Guide developers!

Curious how other admins handle this: we have "Category / Subcategory" style dropdown fields on our ticket forms. By default Zendesk shows every subcategory option no matter what category the agent picked. Agents end up scrolling through irrelevant options, and keeping this in sync via triggers gets messy as the field list grows.I ended up building a small app for this called Conditional Dropdown Filter. It's a free app on the Marketplace that connects a parent and child dropdown field with a visual rule builder. No code, no triggers needed.What it does:Pick which child options are allowed for each parent value Agents instantly see the filtered list in the ticket form Flags rules that reference deleted field options so they don't go stale Runs on Zendesk Custom Objects in your own account, nothing leaves Zendeskhttps://www.zendesk.com/marketplace/apps/support/1275479/conditional-dropdown-filter/Genuinely curious: is everyone else solving this with triggers/conditional fields, or is the

Issue I was trying to solve:We are B2B, and frequently the requests that come in need to be escalated to a super admin within their own Organization. It's hard to keep track of that list of escalation contacts for all clients, especially with turnover.  Solution:I created a Custom Object where I create and maintain the escalation contact list. It includes lookup relationships to the ZD User and the ZD Organization. I used the Builder to create an app in the ticket sidebar, which pulls in that org’s Escalation Contacts from the custom object, along with a few key pieces of info (department, primary/secondary) and buttons to either copy the email address or cc it into the ticket.  Prompt: Build an app for the Ticket Sidebar called Escalation Contacts. Pull the escalation_contacts custom object records. Each custom object record includes a ZD Organization lookup, a ZD User lookup, and ____ fields. Find the records/users associated with the ticket’s Organization, and display their name, em

Problem Statement Administrators may need to bulk delete tickets, such as when a business unit is sold to another company and their associated data must be incrementally removed. The native Zendesk UI does not allow users to select and perform bulk actions on closed tickets. When needing to purge tickets associated with a sold business unit, clicking into individual closed tickets to delete them via the menu is inefficientWhat makes this app special This app overcomes Zendesk's native UI limitations by enabling bulk deletion of closed tickets directly via the API. It includes built-in safety validation to ensure only tickets with a "closed" status are processed, while handling large volumes through batch processing.Core use cases Deleting closed tickets in bulk by specifying multiple ticket IDs separated by commas, spaces, or newlines. Searching and bulk deleting all closed tickets associated with a specific requester's email address. Purging obsolete closed tickets efficiently aft

The goal of this app is to clean up and standardize requester names.  Requester Name Auto-Corrector — What It DoesThis Zendesk ticket sidebar app automatically detects and fixes poorly formatted requester names so agents don't have to clean them up manually. Automatic corrections it applies:Strips stray digits from names (e.g., Kell Mullen2 → Kell Mullen) Reorders last-name-first formats (e.g., Rogers, Shaun A, MD, MPH → Shaun A Rogers, MD, MPH) Title-cases all-lowercase names, including hyphenated names and name particlesSmart detection for uncertain cases:Detects suspicious names — single words (e.g., John), email-prefix usernames (e.g., jsj123), or word-plus-initial patterns (e.g., John S) When a name looks suspicious, scans the ticket conversation for better candidates by looking at requester email signatures, agent greetings (e.g., Hello Tammy,), and requester sign-offs (e.g., Thanks, Charles) Presents found candidates as selectable suggestions with a source label and a "Use this

What is it? This recipe describes how to build a Zendesk Nav Bar app that helps team leaders review skill coverage, assign skills to agents, and manage agent capacity rules.Location: Nav Bar Audience: Team leaders, routing administrators, and workforce managersWhat this recipe solvesManaging Omni-Channel Routing skills across a large team can require several separate Zendesk screens and repeated manual updates. Skill + Capacity Manager provides a single workspace for:Reviewing team skill coverage. Finding skills with no assigned agents. Searching agents by skill. Assigning or removing skills in bulk. Reviewing agent skill assignments. Assigning capacity rules to individual agents or groups of agents. Saving skill changes through an explicit draft-and-save workflow. Demo  Prerequisites Before building the app, confirm that the Zendesk account has:Omni-Channel Routing enabled. Skills and skill values configured. Agents assigned to the relevant groups. Capacity rules configured, if capaci

The ProblemAgents spend significant time searching historical tickets, comparing past resolutions, finding relevant knowledge articles, and piecing together requester context — with real friction:Keyword search alone misses relevant historical tickets. The same issue gets described in different terminology across tickets. Agents manually compare prior resolutions before responding. Customer context (recent product activity) usually isn't visible inside the ticket. New agents have little visibility into how similar issues were resolved before. Teams lack clear insight into recurring root-cause patterns across related tickets.The ChallengeBuild a Ticket Sidebar app that gives agents resolution context without leaving the ticket. It needs to:Understand the customer's actual request before searching. Find semantically similar historical tickets and rank them on multiple relevance signals. Surface previous resolution comments and common resolution patterns. Suggest relevant Help Center arti

App Builder recipe: Agent Stats Dashboard with a gamified neighbourhood sceneProblem StatementAgents rarely get a view of their own numbers. Native dashboards are admin-only or built for managers, and most goal trackers turn into a ranking that makes a slow week feel like a public failure. What agents actually want is a page that answers "how am I doing this week" - and a reason to look at it more than once.What makes this app specialIt runs entirely on ticket APIs that normal agents are allowed to call, so it works without admin rights. Progress towards a personal weekly goal builds up an illustrated neighbourhood scene: an empty street slowly gains buildings, a corner shop, a cafe, a playground, and at 100% the whole street throws a party. Open workload is shown as the weather over the scene - visible, but never shaming. The entire scene is hand-drawn inline SVG, so there are no image assets, no chart library and nothing to host. Per-user state (weekly goal, unlocked items, week hist

App Builder recipe: Forecast - ticket arrival, throughput and staffing needsProblem StatementThe question a team lead actually has to answer is "can I approve holiday for next week without the queue falling over". Explore tells you what happened; it does not tell you how many people you need in the coming weeks. Dedicated workforce management is priced per agent and is a big step for a small team that only wants a defensible number.What makes this app specialIt measures three things and combines them: when tickets arrive, how many a person actually solves per day, and who is away. Arrival is pulled per calendar week and throughput per day over the last four weeks, all through the search export endpoint with cursor pagination - the regular search endpoint has a hard 1000-result cap that silently cuts off the last days of a busy week. Throughput is a median of solved tickets per participating agent, and is corrected by a queue ratio so that absences are not subtracted twice. AI-resolved

 I used Zendesk App Builder to create a small Ticket Sidebar app to reduce repetitive data entry for agents.flow is:Open Ticket > Load Ticket Data > Display Information > Agent Input > Validate > Update Ticket > ConfirmationStep 1: Identify the repetitive actionI focused on one repetitive task instead of automating the complete ticket workflow.The goal was to let agents view the required ticket information and perform the update from one place.Step 2: Create the app in App BuilderFirst, create a Ticket Sidebar app.The form contains:Current ticket subject Current ticket status Relevant ticket information Required input field Action buttonThen go to:Admin Center > Apps and integrations > App Builder  Step 3: Bring ticket context into the appUse the current ticket context to display the required information:Current Ticket >Read Ticket Data > Display in AppThis allows agents to see the ticket information without manually entering it.Step 4: Keep agent input mi

App Builder recipe: Customizable CSAT Dashboard (1-5 scale, not just good/bad)Problem StatementZendesk's customizable CSAT lets you survey on a 1-5 scale, but both Explore and the Satisfaction Ratings API only expose the binary good/bad result. You cannot tell a 5 from a 4, or a 1 from a 3 - which is exactly where the interesting movement happens. Team leads end up with a satisfaction rate and no idea what is behind it.What makes this app specialIt reconstructs the numeric score the API does not hand out. For each rated ticket it walks the ticket audit events, picks up the survey_response_id, and then reads answers[].rating from the survey response - batched and cached so a 30-day range does not melt your rate limit. On top of that it adds brand and group filters, an agent view that defaults to the agent's own ratings, a topic breakdown built on your own ticket field rather than on intent, and an optional playful leaderboard tab. Everything stays inside Zendesk: no comment text is ever

The ChallengeTicket health data is scattered — fields, audits, comments, ticket metrics, custom statuses, CSAT responses. Agents end up hunting for answers to basic questions:How long has the ticket been open (including business hours only)? How long did the first response take? How many times was it reopened? How long did it sit in each custom status? How long did the requester wait? What was the CSAT score? Who handled each reassignment?Manual review is slow and inconsistent. Reopening counts in particular are easy to get wrong — audit events can have missing previous_values, custom statuses may be unavailable, and standard vs. custom status events don't always agree.Goal: a Ticket Sidebar app giving agents a full picture of the current ticket's health without leaving it — a single-ticket view, not a cross-ticket reporting dashboard.Our use case: QA reviewers randomly audit tickets and previously had to dig through the full event/audit history to reconstruct what happened. This app g

The ProblemTicket merges quietly create data quality issues. In a standard merge workflow:Agents can merge tickets without completing required business fields. Conditional fields get missed because they aren't always visible. Source ticket data doesn't carry over to the target. Existing target values get overwritten unnecessarily. Agents can accidentally pick the current ticket as the merge target. The async merge process gives little feedback while it runs.The result: incomplete records, lost context, and inconsistent reporting downstream.Our Use CaseMerges were previously an easy way to lose required data — agents would merge first and fix fields later, if at all, and reporting quietly filled with gaps. Smart Merge forces field completion at merge time and stops target data from being silently overwritten, cutting down cleanup work after the fact.Why not just disable merging? Our Zendesk instance is shared across multiple teams, and merge needs aren't uniform — some teams merge ticke

Like many people, I have been using triggers + webhooks to the Zendesk API, authenticated by API token, to make ticket modifications when there is no native action for what I need. The upcoming elimination of API tokens in favor of OAuth is forcing a change to this configuration, and it looks like Custom Actions & Action Flows might be a good path forward.For example: we have a process where a customer fills out a web form, and the information is sent to Zendesk via email for our agents to process. The ticket is created with the form data in the ticket description (first comment) as a public note. We want to change this to private so it is not visible to the customer when we reply to the ticket.Currently the trigger that runs when these tickets are created notifies the following API-token-authenticated webhook:https://xxx.zendesk.com/api/v2/tickets/{{ticket.id}}/comments/{{ticket.latest_public_comment.id}}/make_private Here is my current approach to replace this. All suggestions fo

Hello,Some of our groups just changed their primary email address. The API update the email address by adding a secondary and keeping their primary as is.  Is there a way to update primary via the API?  

We are using oauth with our api to sync data into zendesk and are looking to limit the scope of our tokens.For the most part this has been fine, however it seems like there are a couple of endpoints we are using that don’t have write scopes (at least documented): organisation_field and custom_objectsThis suggests that we have to use the global write scope for this, which wouldnt be ideal.Is this correct, or did I miss it somewhere? If so, is there a solution/workaround to this?Thanks

Problem StatementThe Proactive Tickets App helps build better relationships with your customers by allowing you to proactively reach out to them via Zendesk Support tickets. The app allows you to search a list of your users based on any searchable user field, and then create tickets in bulk on their behalf.  Location: nav bar Screenshots    Prompt Create a nav_bar app called "Proactive Tickets" that lets agents search for end users, build a ticket template, and bulk-create one support ticket per selected user — then create a Zendesk view to track all those tickets.Add two settings to the app so admins can configure them during installation:`newStatusTicketFieldId` — labelled "Status field ID". Help text: "The ID of the ticket status field. Find it under Admin > Objects and rules > Tickets > Fields." Required, type: number. `numberOfUsersPerPage` — labelled "Users per page". Help text: "Number of users to show per page in the search results." Type: number, default: 20.Read thes

What are the implications of the deprecation of API tokens for local development of themes and apps?Currently, I have a `ZENDESK_API_TOKEN` env var set, along with `ZENDESK_EMAIL` and `ZENDESK_SUBDOMAIN`, so that when I run `zcli themes:preview` or `zcli apps:server` it does its magic and I can develop these things locally.How will this work with OAuth? I’ve implemented the new OAuth workflow for the actual apps that I need to so that production environments work, but how am I expected to continue to develop locally once api tokens are fully deprecated? I’d rather get this taken care of now rather than after it stops working.

Hello, Following your announcement of the removal of API tokens as an authenticationmethod (article 10851263566234: auto-deactivation of unused tokens on2026-07-28, no new tokens after 2026-10-27, full EOL on 2027-04-30), we haveproactively migrated our integrations to OAuth. Our main server-to-serverapplication now authenticates exclusively with client_credentials accesstokens, and we are migrating our remaining API tokens one by one. However, we have identified one integration paths for which no OAuthmigration option currently exists, and we need your guidance on both. We provision our Zendesk users and groups from Microsoft Entra ID using theofficial Zendesk connector from the Microsoft Entra application gallery. Asdocumented by Microsoft(https://learn.microsoft.com/entra/identity/saas-apps/zendesk-provisioning-tutorial),this connector only supports Admin Username + Secret Token (a Zendesk APItoken) for authentication. There is no OAuth option on the Microsoft side. This means that

1: Create the 3 Ticket Fields - Admin Center > Objects and rules > Tickets > Fields 1. Follow-up Required Display name: Follow-up Required Type: Checkbox 2. Follow-up Date Display name: Follow-up Date Type: Date 3. Follow-up Note Display name: Follow-up Note Type: TextGo To App builder;Admin Center > Apps and integrations > Apps > App Builder  Click Start a conversation button.Give instruction to create your app.For example:I want to create this app to work with these three ticket fields:- Follow-up Required – checkbox- Follow-up Date – date- Follow-up Note – textThe app should show the existing follow-up date if one is already set on the ticket.Agents should be able to select a new follow-up date and optionally add a short note.When the agent clicks "Schedule Follow-Up", the app should:- Mark Follow-up Required as Yes- Save the selected follow-up date- Save the follow-up note- Add the "follow_up_required" tag- Keep all existing ticket tags- Show a success message wh

Ciao a tutti,sto cercando un consiglio tecnico riguardo a un'integrazione Zendesk per un sito basato su calcoli dinamici.Gestiamo una piattaforma astrologica dove gli utenti inseriscono dati di nascita e ottengono risultati personalizzati. Una situazione piuttosto frequente è che gli utenti eseguano più calcoli del proprio ascendente prima di contattare l'assistenza, modificando più volte i dati inseriti per verificare eventuali differenze nei risultati.Durante l'integrazione con Zendesk abbiamo riscontrato alcune problematiche legate alla gestione dei ticket.Flusso attualeL'utente completa un processo di calcolo multi-step. Il risultato viene generato in tempo reale. Alcuni utenti effettuano più ricalcoli consecutivi. Successivamente inviano una richiesta di supporto. Zendesk può ricevere più ticket relativi allo stesso utente e alla stessa problematica.Problemi riscontratiCreazione di ticket duplicati dopo invii ripetuti. Difficoltà nel mantenere lo storico delle modifiche effettuate

As you may already know, Zendesk is retiring API tokens in favor of OAuth. Unused tokens will begin deactivating automatically on July 28, 2026, and all API tokens will completely stop working on April 30, 2027. Why the change?API tokens are being replaced with OAuth to deliver safer, short-lived, and precisely scoped access for API-driven workflows. As an industry standard, OAuth provides critical security capabilities that simply cannot be retrofitted into the existing API token architecture. What this means for youIf integrations aren't migrated to OAuth before the deadline, they will stop functioning. The level of impact depends on how heavily your daily workflows rely on legacy API tokens. Join the discussion & upcoming meetup  Whether you're currently mapping out your migration, have run into roadblocks, or have discovered best practices that could help fellow developers, we want to hear from you!​@Ahmed Zaid , Leader of the Developer User Group, is hosting an upcoming meetup

Hello,I am Sakar from Kathmandu , Nepal. Recently started SaaSPal a Product focused company. The biggest challenge I face as a builder is validating my idea and testing with beta users. I have tried cold reaching and cold messaging some but I think should try more.How did you find your first customers ? How did you make your beta tester groups ?

Problem StatementThe Assignment Control app is a ticket sidebar application that provides targeted visibility controls for the ticket assignee dropdown. It dynamically hides specific agents and groups based on configurable targeting rules, such as the current agent's role, group membership, ticket attributes etc. Locations: ticket sidebar, new ticket sidebar PromptCreate a ticket_sidebar app called "Assignment Control" that hides specific agents and groups from the ticket assignee dropdown, based on whether the current agent matches configurable targeting rules.For the locations of ticket sidebar, new ticket sidebarDefine six app parameters in the manifest so they appear on the app's installation settings screen (all type: text, all optional):`hidden_user_ids` — labelled "Hidden users". Help text: "A comma-separated list of user IDs to be hidden from the Assignee dropdown." `hidden_group_ids` — labelled "Hidden groups". Help text: "A comma-separated list of group IDs to be hidden from

Our Azure Function App fails to connect to Zendesk with the following error:ConnectionResetError(104, 'Connection reset by peer')This happens on every request to our Zendesk subdomain — including a simple unauthenticated GET request:requests.get("https://{subdomain}.zendesk.com/api/v2/tickets.json", timeout=10) The same code with the same credentials works fine locally Our Azure NSG allows all outbound internet traffic No IP Restrictions are configured in Zendesk Admin Center (confirmed by our Zendesk admin) Our Zendesk admin confirmed OAuth is configured correctly and tokens can be generated Other third-party APIs (e.g. ZOHO) work perfectly from the same Azure environment using the same requests library Even a basic unauthenticated GET to Zendesk fails — ruling out any OAuth or credential issueHas anyone experienced this before? Is there a known solution or a way to get Azure datacenter IPs whitelisted on Zendesk's infrastructure level?