# Zendesk Destination Config Reference

<p><a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/zendesk/" >Zendesk</a> is a customer support destination. RudderStack creates and updates Zendesk users from <code>identify</code> events and organizations from <code>group</code> events, and records <code>track</code> events as events on the user&rsquo;s profile, from its servers.</p>
<p>In a Zendesk destination spec:</p>
<ul>
<li><code>type: zendesk</code></li>
<li><code>definition_version: 1</code></li>
</ul>
<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="sample-configuration">Sample configuration</h2><div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">version: rudder/v1
kind: destination
metadata:
  name: zendesk-prod
spec:
  id: zendesk-prod
  display_name: Zendesk Production
  type: zendesk
  definition_version: 1
  enabled: true
  config:
    email: &#34;{{ .ZENDESK_EMAIL }}&#34;
    api_token: &#34;{{ .ZENDESK_API_TOKEN }}&#34;
    domain: acme
    source_name: Acme Web

    create_users_as_verified: false
    send_group_calls_without_user_id: false
    remove_users_from_organization: false
    search_by_external_id: true

    connection_mode:
      web: cloud
      cloud: cloud
    consent_management:
      web:
        - provider: oneTrust
          consents:
            - analytics</code></pre></div>
</div>
<p>The above example makes the email in each <code>identify</code> event the user&rsquo;s primary email in Zendesk — which is what <code>search_by_external_id</code> does, despite its name. See <a href="#users-and-organizations" >Users and organizations</a>.</p>
<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="config-keys">Config keys</h2><p><code>config</code> accepts only the keys listed below. The <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/destination-types/#config-key-rules" >shared config key rules</a> cover unknown keys, defaults, and immutability.</p>

<html lang="en">
<blockquote class="info">
  <div class="tip-quote">
    
    <div class="tip-text">Zendesk accepts only <code>identify</code>, <code>group</code>, and <code>track</code> events. <code>identify</code> and <code>track</code> events need a <code>userId</code>, and a <code>track</code> event also needs the user&rsquo;s <code>email</code> trait.</div>
  </div>
</blockquote>

</html>
<!-- end-chunk -->
<!-- begin-chunk -->
<h3 id="connection">Connection</h3><div class="rs-ckeys">
<div class="rs-ckey" id="email">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">email</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Email address of the Zendesk agent or admin RudderStack authenticates as, together with <code>api_token</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks. The email format isn&rsquo;t checked.</li>
<li>A <code>{{ path || fallback }}</code> template is accepted in place of a literal.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.
</div>

</div>

<div class="rs-ckey" id="api_token">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">api_token</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Zendesk API token, used with <code>email</code> for API token authentication.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks.</li>
<li>A spec that omits this key fails validation with <code>'api_token' is required</code>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <p>Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.</p>
<p>See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/zendesk/#connection-settings" >Connection settings</a> for how to generate a token.</p>

</div>

</div>

<div class="rs-ckey" id="domain">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">domain</p>Required</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Your Zendesk subdomain, without <code>.zendesk.com</code> — <code>acme</code> for <code>acme.zendesk.com</code>. The dashboard calls it <strong>Zendesk Subdomain</strong>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks.</li>
<li>A <code>{{ path || fallback }}</code> template is accepted in place of a literal.</li>
<li>Rudder CLI doesn&rsquo;t check the format, so a full host such as <code>acme.zendesk.com</code> passes <code>validate</code>, and then breaks delivery.</li>
</ul>

</div>

</div>

<div class="rs-ckey" id="source_name">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">source_name</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Source RudderStack records on the Zendesk events it creates from <code>track</code> calls. When omitted, RudderStack uses <code>Rudder</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>At most 100 characters, and must not contain line breaks.</li>
<li>A <code>{{ path || fallback }}</code> template is accepted in place of a literal.</li>
<li><code>zendesk</code> is reserved, in any capitalization. Rudder CLI accepts it, but RudderStack then fails every <code>track</code> event.</li>
</ul>

</div>

</div>

</div>

<!-- end-chunk -->
<!-- begin-chunk -->
<h3 id="users-and-organizations">Users and organizations</h3><div class="rs-ckeys">
<div class="rs-ckey" id="create_users_as_verified">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">create_users_as_verified</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Create users as verified, so Zendesk skips its email verification for them.
</p>

</div>

<div class="rs-ckey" id="send_group_calls_without_user_id">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">send_group_calls_without_user_id</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Let a <code>group</code> event without a <code>userId</code> create or update the organization on its own. When <code>false</code>, a <code>group</code> event needs a <code>userId</code>, and RudderStack adds that user to the organization.
</p>

</div>

<div class="rs-ckey" id="remove_users_from_organization">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">remove_users_from_organization</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Let an <code>identify</code> event remove the user from an organization. The event&rsquo;s traits name the organization&rsquo;s Zendesk ID in <code>company.id</code>, and set <code>company.remove</code> to <code>true</code>.
</p>

<div class="rs-ckey__extra">
  See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/zendesk/#removing-users-from-an-organization" >Removing users from an organization</a>.
</div>

</div>

<div class="rs-ckey" id="search_by_external_id">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">search_by_external_id</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Make the email in an <code>identify</code> event the user&rsquo;s primary email in Zendesk, replacing the previous one. When <code>false</code>, RudderStack adds that email as a secondary email if the user already has a primary one.
</p>

<div class="rs-ckey__extra">
  <blockquote class="warning">
  <div class="tip-quote">
    
    <div class="tip-text">Despite its name, this key doesn&rsquo;t change how RudderStack finds users. It&rsquo;s the setting the dashboard calls <strong>Update user&rsquo;s primary email</strong>.</div>
  </div>
</blockquote>
<p>See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/zendesk/#updating-users-primary-email-in-zendesk" >Updating user&rsquo;s primary email in Zendesk</a>.</p>
</div>

</div>

</div>

<!-- end-chunk -->
<!-- begin-chunk -->
<h3 id="per-source-keys">Per-source keys</h3><p>Both keys are objects keyed by the local source type — the tokens listed under <a href="#source-types" >Source types</a>. A key naming a source type this destination doesn&rsquo;t support fails validation.</p>
<div class="rs-ckeys">
<div class="rs-ckey" id="connection_mode">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">connection_mode</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Maps each source type you connect to the mode its events reach Zendesk in, using the modes in <a href="#source-types" >Source types</a>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>An entry is required for each source type you connect — see <a href="#connect-a-source" >Connect a source</a>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">connection_mode:
  web: cloud
  cloud: cloud</code></pre></div>
</div>

</div>

</div>

<div class="rs-ckey" id="consent_management">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">consent_management</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Consent provider configuration per source type. The entry shape, accepted providers, and the rules on <code>resolution_strategy</code> and <code>consents</code> are shared across all destination types — see <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/destination-types/#consent-management" >Consent management</a>.
</p>

</div>

</div>

<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="source-types">Source types</h2><p>Zendesk accepts events from these source types in the mentioned connection modes:</p>
<table>
  <thead>
      <tr>
          <th>Source type</th>
          <th>Connection mode</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><code>android</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>android_kotlin</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>ios</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>ios_swift</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>web</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>unity</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>react_native</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>flutter</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>cordova</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>cloud</code></td>
          <td><code>cloud</code></td>
      </tr>
      <tr>
          <td><code>warehouse</code></td>
          <td><code>cloud</code></td>
      </tr>
  </tbody>
</table>
<p>Every source type is <code>cloud</code> only — events reach Zendesk from RudderStack&rsquo;s servers, never in device mode.</p>

<p><code>warehouse</code> is the token a <a href="https://www.rudderstack.com/docs/sources/reverse-etl/" >Reverse ETL source</a> resolves to. Rudder CLI manages the destination’s <code>warehouse</code> entry — if the destination is connected to a Reverse ETL source, set <code>connection_mode.warehouse: cloud</code> in its spec, or <code>apply</code> removes it.</p>
<p>Rudder CLI can also declare the Reverse ETL connection itself, for the types listed under <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/yaml-retl-connections/#supported-destinations" >Supported destinations</a> — see <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/retl-connections/" >Manage Reverse ETL Connections using Rudder CLI</a>.</p>

<html lang="en">
<blockquote class="info">
  <div class="tip-quote">
    
    <div class="tip-text">The dashboard additionally offers Zendesk to AMP and Shopify sources. Rudder CLI doesn&rsquo;t manage those connections, so <code>amp</code> and <code>shopify</code> are invalid here.</div>
  </div>
</blockquote>

</html>
<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="connect-a-source">Connect a source</h2><p>An event stream connection to this destination is checked against two rules at <code>validate</code> time.</p>
<p><strong>The source&rsquo;s type must be supported.</strong> A source&rsquo;s type resolves to one of the tokens above before the check — a JavaScript source resolves to <code>web</code>, and webhook and server-side SDK sources resolve to <code>cloud</code>. Every type an event stream source can resolve to is supported here, so this check always passes.</p>
<p><strong>The destination config must carry a <code>connection_mode</code> entry for that source type.</strong> This lives on the destination spec, not on the <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/yaml-connections/" >connection spec</a>. Without it:</p>
<div class="rs-code">
  <div class="rs-code__head"><button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-text" data-lang="text">destination &#39;zendesk-prod&#39; config has no &#39;connection_mode&#39; entry for source type &#39;web&#39;</code></pre></div>
</div>
<p>Zendesk needs no additional config keys to connect a source of any type.</p>
<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="secrets">Secrets</h2><p><code>email</code> and <code>api_token</code> are the secret keys. Write each as a <code>{{ .VAR }}</code> reference and supply the value at apply time:</p>
<div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">config:
  email: &#34;{{ .ZENDESK_EMAIL }}&#34;
  api_token: &#34;{{ .ZENDESK_API_TOKEN }}&#34;</code></pre></div>
</div>
<div class="rs-code">
  <div class="rs-code__head">bash<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-bash" data-lang="bash">export RUDDER_ZENDESK_EMAIL=&#34;...&#34;
export RUDDER_ZENDESK_API_TOKEN=&#34;...&#34;
rudder-cli apply

# or
rudder-cli apply --var-file secrets.vars.yaml</code></pre></div>
</div>
<p>Note that:</p>
<ul>
<li><code>rudder-cli import</code> writes only the secrets the API returns, as <code>{{ .VAR }}</code> references, and leaves the others out. Add any secret key it leaves out, then supply the variables before you apply — see <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/destination-types/#secrets" >Secrets</a>.</li>
</ul>
<p>See <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/variable-substitution/" >How to Use Variable Substitution in Rudder CLI</a>.</p>
<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="changes-by-release">Changes by release</h2>
<p>No changes since this type became available.</p>
<p>For changes across every destination type, see <a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/destination-types/changes/" >Destination Type Changes by Release</a>.</p>
<!-- end-chunk -->
<!-- begin-chunk -->
<h2 id="see-more">See more</h2><ul>
<li><a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/zendesk/" >Zendesk Destination</a> for API token setup, attribute mapping, and organization membership</li>
<li><a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/destination-types/" >Destination Type Reference for Rudder CLI</a> for the rules shared across destination types</li>
<li><a href="https://www.rudderstack.com/docs/dev-tools/rudder-cli/yaml-destinations/" >Destination YAML Reference</a> for the spec envelope</li>
</ul>

