Embed LiKE AI search into your applications, website, or internal systems. Three integration methods: REST API, JS widget, iframe.
#REST API
Plan availability. The public API and the public widget work only on plans that include them (see Plans and billing). On other plans you can't create a key or a public widget, and existing ones stop responding: a request with a key gets
403, and the widget button does not appear on the site. The corporate widget does not depend on this flag.
#Step 1 — Create an API key
- Integrations → Public API → "Create key"
- Enter a name (for example, "Mobile app")
- Copy the key — it is shown only once
#Step 2 — Use the API
All requests are authorized via the header:
X-API-Key: your-key#Core endpoints
| Endpoint | Method | Description |
|---|---|---|
/api/public/search |
POST | AI search across the knowledge base |
/api/public/toc |
GET | Table of contents of public articles |
/api/public/articles |
GET | List of public articles |
/api/public/articles/{id} |
GET | Article content |
#Example: AI search
curl -X POST https://your-account.lynkora.pro/api/public/search \
-H "X-API-Key: $API_KEY" \
-H "Content-Type: application/json" \
-d '{"q": "Как оформить отпуск?"}'Response:
{
"answer": "Для оформления отпуска...",
"sources": [
{"title": "Политика отпусков", "url": "..."}
]
}#Rate limits
API requests are throttled per key; when the limit is exceeded, HTTP 429 is returned with a Retry-After header.
#Security
- Store keys in environment variables, not in code
- Create a separate key for each application
- Delete unused keys
- Restrict domains in the key settings
#JS widget
A floating AI search button to embed on any website.
#Step 1 — Get the code
- Integrations → Channels → the "JS Widget" card → "Manage widgets" → "Create widget". Enter the "Address of the site where the widget will live"
- Configure the parameters (see the table below)
- Copy the code
#Step 2 — Add it to your site
Insert the copied <script> before the closing </body> tag:
#Where to paste the code in website builders
The code is the same for every site — no need to change it: the widget finds itself on the page wherever the builder puts the line. The only difference is where to paste it.
Any site (HTML). Paste the code before the closing </body> tag on every page that needs search — or into the site's shared template.
WordPress. Install the WPCode plugin (Insert Headers and Footers) → Code Snippets → Header & Footer → paste the code into Footer → Save Changes. On WordPress.com, plugins are not available on every plan.
Tilda. For the whole site: Site Settings → More → HTML code for the HEAD section → paste the code → Save → republish all pages. For one page: add the Other → T123 (HTML code) block and paste the code into it.
Wix. In the site dashboard open Settings → Custom Code (depending on the interface version — under "Advanced" or "Development & integrations") → Add Custom Code → paste the code → All pages → Body — end → Apply. Do not use the "Embed HTML" element on a page: it opens in a frame on a different address, and the widget will not work there. Custom code in Wix is available on a premium plan with a connected domain.
Webflow. Site settings → Custom code → Footer code → paste the code → Save → publish the site. Site-wide custom code is available on paid site plans.
Squarespace. Open Code Injection (in the site settings; depending on the interface version — under Developer tools or Website Tools) → paste the code into Footer → Save. Code injection is not available on every plan.
Shopify. Online Store → Themes → … → Edit code → the layout/theme.liquid file → paste the code before </body> → Save.
Framer. Site Settings → General → Custom Code → paste the code into End of tag → publish the site.
Google Tag Manager. Tags → New → Custom HTML → paste the code → trigger All Pages → Save → Publish the container.
Docusaurus. The code goes into docusaurus.config.js, with the same key:
scripts: [
{
src: 'https://your-account.lynkora.pro/api/public/widget.js',
'data-key': 'wk_live_YOUR_KEY',
async: true,
},
],Site addresses. The widget works only on the addresses in Allowed origins, and the address is matched exactly: example.com and www.example.com are two different addresses — add both. If you test the site on the builder's preview address (for example *.tilda.ws, *.wixsite.com, *.webflow.io, *.myshopify.com), add it too.
The button did not appear? Check three things: the widget is enabled; the page address is in Allowed origins — exactly, with or without www; the code is in the site settings or template, not in an element the builder opens in a frame.
#Widget parameters
| Parameter | Value | Description |
|---|---|---|
data-key |
wk_live_... |
Required. The widget key (created in Integrations → Channels → JS Widget). Without it, the widget will not start |
data-position |
bottom-right / bottom-left / none |
Position of the floating button (default bottom-right) |
data-theme |
light / dark / auto |
Visual theme (default light; auto follows your website's theme) |
data-lang |
ru / en / de / es / fr / it / pt / ko / sr / sr-Cyrl / zh / ar |
Default language. Used only when the visitor's language is unknown: the visitor's choice and their browser languages take priority. If none fits — English |
data-hotkey |
k |
Open key combined with Cmd/Ctrl (default k → Cmd/Ctrl + K) |
data-session-token |
JWT | Optional. Session token for per-user identity mode (see "Comparison of authentication modes" below) |
#Result
A button appears in the corner of your site (its color comes from the widget settings). Click → a chat window with a question field → an AI answer from your knowledge base.
#Language
The visitor changes the language with the globe button in the window header; the choice is remembered in their browser for this widget. Without a choice, the widget takes the first suitable language from the browser languages, then the language from the widget settings (data-lang), then English. The language of your site's page is not considered. In Arabic the window opens right-to-left.
#Binding to a site
The widget works only on the addresses specified at creation ("Address of the site where the widget will live"); requests from other sites are rejected. Separate several addresses with commas. The widget can't be enabled without an address, and an asterisk for "any site" is not accepted. The address is compared exactly: example.com and www.example.com are different addresses — specify both if the site opens at both. For local testing, specify the address with a port, for example http://127.0.0.1:8899.
#What the visitor sees
- The answer text has no source markers like
[2.3]; headings and links are formatted. - Under the answer there is a "Sources" block: the link leads to the original source page, or, if there is none, to the article.
- The "Open full search" link is present only in the corporate widget.
#If the AI-answer limit is used up
The public widget is hidden from the site entirely until the limit comes back. The corporate widget stays in place but does not accept questions and shows when search will be available again.
#iframe
A full-featured search interface embedded on your page:
#Embed code
/embed is the only portal address allowed to open inside a frame on someone else's site. The portal root (https://your-account.lynkora.pro) cannot be embedded — the browser will refuse. The frame needs no key: it works anonymously and shows exactly what an anonymous portal visitor sees; its scope comes from the widget settings.
#Direct link
If an iframe does not suit you, give users a direct link: https://your-account.lynkora.pro
#Demo mode
For testing without an API key, a demo endpoint is available with limitations:
| Parameter | Value |
|---|---|
| Authorization | Not required |
| Limits | A per-address request limit applies. On exceeding it, HTTP 429 is returned with a Retry-After header |
| Purpose | Getting to know the API. For production load, create a key |
Endpoint: POST /api/public/demo/search
#Comparison of authentication modes
The widget supports two authentication modes.
#Mode A — Trust the URL zone
Client-side authentication: you are responsible for who reaches the pages with the widget (VPN, SSO, protected routes). Lynkora does not know the user's identity — only the request's Origin/IP. The widget is visible to everyone who opens a page with the embed code.
- Backend code: 0 lines
- Onboarding time: ~2 minutes
- Suitable for: intranet, internal portal
#Mode B — Session token (per-user JWT)
Your backend issues a short-lived session token for each user. Lynkora knows the identity, keeps an audit per user, and supports revocation and GDPR DSAR.
- Backend code: ~10 lines (via SDK)
- Onboarding time: 1–2 hours
- Suitable for: multi-tenant SaaS, regulated industries
| Mode A — URL zone | Mode B — Session token | |
|---|---|---|
| User identity | no (Origin/IP only) | yes (per-user JWT) |
| Audit per user | no | yes |
| Revocation / GDPR DSAR | no | yes |
| Backend code | 0 lines | ~10 lines (SDK) |
| Onboarding | ~2 minutes | 1–2 hours |