The /help-articles endpoint gives you read-only access to all UniLink Help Center content — filterable by language and category for building custom support UIs and syncing content externally.
- Base path is
https://unilink.us/api/v1/help-articles— read-only GET endpoint (list and single). - Filter results by
lang,category, andpublishedquery parameters. - Response fields include
slug,title,content,lang,category, andupdated_at.
The UniLink help articles endpoint provides programmatic access to all published Help Center content. This read-only API is designed for use cases where you need to surface UniLink's support documentation outside the default Help Center interface — embedding relevant articles in your own application, syncing content to an external knowledge base platform, or building a branded customer support experience. Because the endpoint is read-only, it works with any API key scope, including read-only keys.
What the Help Articles Endpoint Does
The /help-articles endpoint supports two operations. GET /help-articles returns a paginated list of help articles. Without any filters, it returns all published articles across all languages and categories. You can narrow results using the lang query parameter (ISO 639-1 language code), the category parameter (category slug), and the published parameter (boolean — defaults to true when omitted, returning only published articles). GET /help-articles/{slug} returns the full content and metadata for a single article identified by its URL slug.
Each article in the response includes the following fields: id (internal integer identifier), slug (URL-safe string used as the canonical identifier), title (plain text headline), content (HTML string, the full article body), excerpt (short plain-text summary), lang (two-letter language code), category (category slug and display name), published (boolean), created_at, and updated_at (ISO 8601 UTC timestamps). The updated_at field is particularly useful for incremental sync workflows — fetch only articles where updated_at is after your last sync timestamp.
The help articles endpoint is intentionally read-only. UniLink manages Help Center content centrally to ensure accuracy and consistency across all customers. This design means your integrations always have access to the most current, reviewed documentation without the risk of client-side writes introducing errors or out-of-date content. If you need to create or modify help articles, that must be done through the UniLink dashboard by your account's content team.
How to Get Started
- Generate a read scope API key from Settings → API — the help articles endpoint requires no special permissions beyond read access.
- Make a basic list request to see what is available:
GET https://unilink.us/api/v1/help-articles?limit=10. Review the response structure and note the category slugs used in your account. - Filter by language to fetch articles in a specific language:
GET /help-articles?lang=en&limit=100. Add&lang=uato fetch Ukrainian translations, for example. - Fetch a single article by slug:
GET /help-articles/how-to-add-a-link-block. This gives you the fullcontentHTML field, which is not included in the list response for performance reasons. - Build a sync script that calls
GET /help-articles?updated_after=LAST_SYNC_TIMESTAMPon a schedule to incrementally update your local content mirror as articles are updated.
How to Use the Help Articles Endpoint
- Build a custom Help Center UI: Fetch all published articles for your preferred language on page load with
?lang=en&published=true. Group bycategoryto build a sidebar navigation. Fetch the full article on demand withGET /help-articles/{slug}when a user clicks through. - Embed contextual help in your app: In your application UI, identify relevant article slugs for each feature or page. Fetch those specific articles by slug and render the content inline or in a slide-out panel, reducing support ticket volume.
- Sync to an external knowledge base: Use a scheduled job to fetch all articles with
?updated_after=LAST_RUNand upsert them into Zendesk, Intercom, Freshdesk, or any other help platform using that platform's own API. The slug serves as the external ID for deduplication. - Multi-language support: Fetch articles in each language you support by iterating through language codes:
?lang=en,?lang=ua,?lang=es. Store each language version separately indexed by slug + lang for fast lookup in your UI. - Build a search index: Fetch all articles, extract the
title,excerpt, andcontentfields, and index them in your search engine of choice (Algolia, Elasticsearch, MiniSearch). Update the index wheneverupdated_atchanges on an article.
Key Settings
| Setting | What It Does | Recommended |
|---|---|---|
| lang filter | Filters articles by two-letter language code (en, ua, etc.) | Always specify lang in production to avoid mixing language versions in your UI |
| category filter | Filters articles by category slug | Fetch per-category to build structured navigation — don't fetch all and filter client-side |
| published filter | Returns only published articles when true (default) | Use published=true in production; set to false in dev to preview draft articles |
| updated_after filter | Returns only articles updated after a given timestamp | Use for incremental sync — store the last sync timestamp and fetch only changed articles |
| limit parameter | Number of articles per page (default 20, max 100) | Use limit=100 for sync jobs; use 20 for paginated UI navigation |
content HTML field — it returns only title, excerpt, slug, category, lang, and timestamps. This keeps list responses fast. Always make a follow-up GET /help-articles/{slug} request to fetch the full content when a user selects an article to read.
Get the Most Out Of the Help Articles Endpoint
Cache help article content aggressively. Help Center articles change far less frequently than user data. A cache TTL of 1–4 hours is appropriate for most use cases. Store the updated_at timestamp alongside the cached content so you can invalidate the cache selectively when an article is updated, rather than expiring all cached content simultaneously.
Use the category structure to build hierarchical navigation in your custom Help Center UI. The category field in each article response includes both a machine-readable slug and a human-readable name. Fetch all categories first with GET /help-articles/categories, build your navigation tree, then lazy-load articles for each category as users navigate. This pattern delivers a fast initial load with full content depth available on demand.
For contextual in-app help, map your application routes to specific article slugs in a configuration file. When a user opens the help widget on a given page, look up the mapped slug and fetch that article directly. This approach surfaces the most relevant help content without requiring users to search, reducing time-to-answer and increasing the chance the user resolves their question without contacting support.
When syncing to an external help platform, preserve the UniLink article slug as a custom field or tag in the external system. This creates a stable link between the canonical UniLink source and the external copy, making it easy to reconcile updates — if the UniLink article slug changes or is archived, you can find the corresponding external record and update or remove it accordingly.
Troubleshooting
| Problem | Cause | Fix |
|---|---|---|
| Article content field is missing from list response | List endpoint returns metadata only for performance — content is excluded by design | Fetch the full article using GET /help-articles/{slug} to get the content HTML field |
| 404 on a slug that exists in the dashboard | Article is a draft (published: false) and you are using the default published=true filter | Add &published=false to your request, or publish the article in the dashboard first |
| Sync job fetching same articles repeatedly | updated_after filter not being applied, or timestamp stored incorrectly | Confirm the timestamp is ISO 8601 UTC format and URL-encoded in the query string |
| Mixed languages appearing in results | lang filter omitted from request | Always include &lang=en (or your target language) explicitly — the default returns all languages |
- Read-only design requires only read scope — no risk of accidental writes from integration code
- updated_after filter enables efficient incremental sync without fetching unchanged content
- Multi-language support via lang filter makes international Help Center builds straightforward
- Consistent HTML content field enables clean rendering without custom parsing logic
- Read-only — cannot create or update help articles programmatically; dashboard only for writes
- Full content not available in list endpoint — requires a separate request per article to get HTML body
- No webhook support for help article changes — sync must be pull-based on a schedule
Can I create or update help articles via the API?
No. The /help-articles endpoint is read-only. Help Center content is managed exclusively through the UniLink dashboard to ensure accuracy. Only GET requests are supported.
Does the list endpoint return the full article HTML content?
No. The list endpoint returns metadata only: slug, title, excerpt, category, lang, and timestamps. Fetch GET /help-articles/{slug} to get the full content HTML field for a specific article.
How do I fetch only articles updated since my last sync?
Use the updated_after query parameter with an ISO 8601 UTC timestamp: ?updated_after=2025-05-01T00:00:00Z. Store the timestamp from your last successful sync run and use it on the next run to fetch only changed articles.
What languages are available in the Help Center?
Available languages depend on your UniLink account's content configuration. Use GET /help-articles/languages to fetch the list of available language codes. Common values are en (English) and ua (Ukrainian).
Is the help articles endpoint rate limited?
Yes — all API endpoints share the same per-key hourly rate limit. For sync jobs that fetch many articles, use limit=100 and the updated_after filter to minimize request count. Cache results locally to avoid refetching unchanged content.
- The help articles endpoint is at
https://unilink.us/api/v1/help-articles— read-only, no writes. - Filter with
lang,category,published, andupdated_afterto get exactly the articles you need. - List responses include metadata only — use
GET /help-articles/{slug}for the full HTML content. - Use
updated_afterwith a stored timestamp for efficient incremental sync without re-fetching unchanged content. - Cache article content aggressively (1–4 hours TTL) — help articles change infrequently and caching reduces API usage significantly.
Start integrating UniLink Help Center content into your app — generate a read-scope API key at app.unilink.us under Settings → API.
