Zendesk Federated Search
Your answers live in four places and your customers search one of them. Zendesk federated search pulls the other three into the help centre results.
What Zendesk federated search actually does
Federated search lets external content appear in help centre search results alongside your articles and community posts.
External means anything outside Zendesk: developer documentation on its own domain, a blog, a status page, a training portal, product release notes maintained by engineering in a repo nobody wants to migrate.
The clarification that saves the most disappointment: this isn't a web crawler. Zendesk doesn't go and read your documentation site. You push records to Zendesk, and Zendesk indexes what you pushed. Everything else about the feature follows from that one fact.
How records get in
The model has three pieces. A source describes where content comes from, such as "Developer docs". A type describes what the content is, such as "Reference page". And an external record is one indexed item.
You create the source and type once, then push records. Each record carries a title, a body, a URL back to the real page, a locale, and an id you control.
curl -s -u you@example.com/token:APITOKEN -X POST \
-H "Content-Type: application/json" \
-d @record.json \
https://acme.zendesk.com/api/v2/guide/external_recordsA record looks roughly like this.
{
"external_record": {
"external_id": "docs-4471",
"title": "Rotating an API key",
"body": "Open Settings, then API, then Rotate.",
"url": "https://docs.acme.com/security/api-keys",
"locale": "en-us"
}
}Endpoint paths and required attributes for this feature have changed across releases, and the source and type ids are account-specific, so treat the above as the shape rather than the contract and check the current Zendesk developer docs before you write the sync.
The body you push is what gets searched. That's a design decision, not a formality: push the full text, not a summary, or your content will be findable by title only.
The setup in practice
Four steps, and the fourth is the one that takes real time.
Handle deletions explicitly. A page removed from your docs site does not disappear from the index by itself, and a search result leading to a 404 is worse than no result.
Limits worth knowing first
Ranking is largely out of your hands. External records compete with articles in the same result set, and you don't get a knob that says "always rank docs above community". Titles and body text do the work.
The help centre search experience is what it is. Federated results appear in it, and if the underlying search doesn't handle your terminology well, adding more content does not fix that.
It's a plan-gated feature, and the availability has changed over time. Check yours before designing around it.
There are practical ceilings on record counts and payload sizes too. For a documentation site of a few thousand pages this is a non-issue. For indexing an entire forum archive, read the limits first.
Is it worth doing
It earns its keep when two things are both true: you have substantial content outside Zendesk that customers genuinely need, and that content is generated from something machine-readable.
Developer-facing companies are the obvious case. The API reference lives with the code, the help centre has the account and billing articles, and customers do not know or care which is which. They search once.
It is not worth it if the external content is thin, or if the honest fix is to move a dozen pages into the help centre and be done. Building a sync pipeline to index fifteen pages is a hobby, not a project.
There is a middle case that catches people out. Teams with a large but stale external wiki look at federated search and see a way to make all that content findable without migrating it. Resist. Indexing content nobody has updated in three years makes your search results worse, not better, because a confidently wrong answer at the top of the page costs more than an empty result. Prune first, index second.
If you do go ahead, measure it. Search analytics will tell you whether federated results get clicked, and whether ticket volume on the topics you indexed actually moved. A pipeline nobody has checked in six months is exactly as useful as no pipeline.
Frequently asked questions
What does federated search setup involve?
Pushing records in. Zendesk federated search setup means indexing external content through the API, and once done, Zendesk search external content appears alongside articles. Zendesk external content search only covers what you've pushed.
What's Zendesk federated search?
A way to index content from outside Zendesk so it appears in help centre search results alongside your knowledge base articles and community posts.
Does Zendesk crawl my external site?
No. There's no crawler. You push records to Zendesk through the API and Zendesk indexes what you send, which means you also own keeping it fresh.
Can I control how external results rank?
Not directly. External records compete with articles in the same result set, so title and body text are the levers you have.
What plan do I need for federated search?
It's gated by plan and availability has shifted over time. Check the current Zendesk documentation against your subscription before designing around it.
How do I remove indexed external content?
Delete the record explicitly through the API. Removing the page from your site doesn't remove it from the Zendesk index.
Better answers, fewer repeat tickets
Findable documentation stops some tickets. For the ones that still arrive twice, Ticket Merger handles the rest.
Start free trial14-day free trial. No credit card required.