Start here
Appilot adds AI to a web application without changing it. The assistant helps people operate the app, and it acts on their behalf through capabilities you define. It reaches your users two ways, as an embeddable widget and as a Chrome extension, and both run on the same configuration.
Appilot is not generally available and has no public sign-up. Accounts are issued by invitation, and the assistant is meant to run against test systems and test data while the beta runs.
Request access at appilot.space. Talk to us before you point it at a live application, so we can agree the terms a production deployment needs, including its data protection agreement.
Find your path
| What you are doing | Start here |
|---|---|
| Adding the assistant to an app you own, with a coding agent | End to end with the widget |
| Adding it to an app you cannot change | End to end with the extension |
| Working on your own machine | Develop on localhost |
| Wiring your app's own users into it | The identity relay |
| Letting the agent call your app's functions | Client actions |
| Configuring an app by talking to ChatGPT, Claude, Cursor or Codex | Configure with AI |
| Configuring someone else's app for them | Who can configure |
| Proving you control a hostname | Verify your domain |
| Promoting a configuration between environments | Config backups and the MCP reference |
| Running Appilot inside your own network | On-premise |
| Building a conversation that is itself the unit of work | Focused Sessions |
| Wiring it by hand, without an AI client | Widget installation |
The fastest thing that works
On a domain you have registered in the Backoffice, this is the whole integration:
<script type="module" src="https://cdn.appilot.space/widget/v1/appilot.esm.js"></script>
<script nomodule src="https://cdn.appilot.space/widget/v1/appilot.js"></script>
No key: Appilot resolves your organization from the page's domain. The launcher appears in the corner of the page.
One thing is still missing, and it is deliberate. Appilot serves identified users only, so the panel will ask for an identity before it will chat. Give it one of the three: your own users through the identity relay, the widget's built-in sign-in, or your corporate SSO. The choice is laid out in Identity and sign-in.
Or start from the AI client you already use
Connect Appilot to Claude, ChatGPT, Cursor or Codex and configure your app by talking to it. The agent provisions the app, writes the integration code into your repository, reads your screens to author controls, and audits the result against the health contract. Nothing is installed: the client connects to a URL.
https://mcp.appilot.space/mcp
Mint a service token in the Backoffice under Admin, Service tokens, choose the Set up integrations preset, and approve the connection. Then say what you want:
Add Appilot to this app, provision it for app.example.com, and make the booking flow something the assistant can complete end to end.
Full walkthrough: Configure with AI.
The names, once
Four credentials, and they are not interchangeable.
| Name | Looks like | Lives in | Does |
|---|---|---|---|
| Widget key | wk_live_..., wk_test_... | Your page, in the open | Names the organization where the page's domain cannot |
| Widget secret | wsk_secret_... | Your backend's environment | Proves you hold the key, so your backend can mint user identities |
| User token | an opaque JWT | The browser, for an hour | Names one of your users on every turn |
| Service token | appilot_pat_... | An MCP client's credential store, or CI | Lets an agent or a script read and write configuration |
The widget key is publishable: it ships in your HTML on purpose, the way a payment provider's publishable key does. The other three are secrets.
Three scope presets exist for a service token, and the Backoffice, the consent screen and these docs call them the same thing:
| Preset | Scopes | For |
|---|---|---|
| Inspect only | config:read | Auditing |
| Edit configuration | config:read, config:write, feedback:write | Authoring |
| Set up integrations | the above plus provision:write | Creating apps, domains and keys |
What makes the assistant good
Installing it takes minutes. Making it useful is the work, and it is the same work whichever surface you chose:
- Knowledge carries the meaning: rules, terminology, what a field is for. Author it scoped to the views it belongs to.
- Views tell the assistant which screen the user is on.
- Controls and forms are the elements it can point at and operate.
- Action plans are the procedures. A procedure lives in a plan, never in a knowledge article.
- Tools and client actions are how it acts: server side through an HTTP-proxy tool, in the page through a client action.
Authoring for the agent is the mental model behind those five.
How the widget sits in your page
The widget is a Web Component with a closed Shadow DOM. Your styles do not reach
it and its styles do not reach you. It reads the host page's structure for
context, with no iframe in between, and it mounts under <html> rather than
inside your body so it never disturbs your own stacking or focus handling.
For the request path, the tenancy model and the security boundaries, see Architecture.