Add the Allinaa chatbot to a Laravel application
Written by the Allinaa team · Updated
In a Laravel application the widget belongs in the Blade layout your public pages extend, and the bot id belongs in configuration rather than in a template. That takes two minutes longer than pasting it and saves the next developer from finding a hard-coded identifier in a view.
Before you start: copy your embed code
Create your account at bot.allinaa.com/start using your site's address. The setup wizard reads your own public pages and drafts the knowledge from them so you can edit and approve it. Step 5, "Install", shows your line with a copy button:
<script src="https://bot.allinaa.com/widget.js" data-bot-id="your-bot-id" defer></script>
Where it goes: your Blade layout
Open the layout your public pages extend - commonly resources/views/layouts/app.blade.php - and put the tag just before the closing body tag:
@stack('scripts')
<script src="https://bot.allinaa.com/widget.js" data-bot-id="your-bot-id" defer></script>
</body>
</html>
Put the bot id in config, not in the view
Add it to your environment file and read it through config, so staging and production can differ and nothing identifier-shaped is hard-coded in a template. The bot id is not a secret - it is visible in the page source by design - but an environment value is still the right home for it, because it changes per deployment target.
# .env
ALLINAA_BOT_ID=your-bot-id
// config/services.php
'allinaa' => ['bot_id' => env('ALLINAA_BOT_ID')],
In the layout, replace the literal id with Blade's echo of config('services.allinaa.bot_id') inside the data-bot-id attribute, and wrap the whole tag in an @if on the same value. A local environment with no value then has no widget at all, rather than a tag carrying an empty id - which is the failure that looks like a broken product.
Keep it off the authenticated side
This is the decision worth making deliberately in an application rather than on a brochure site. A signed-in user's dashboard, a billing page and a checkout are all places where a public chat widget is wrong: the visitor is a customer with an account-specific question the assistant cannot answer, and a chat bubble over a payment form is a distraction at the worst possible moment. If your application has separate layouts for guest and authenticated pages - which Laravel's starter kits do - put the tag only in the guest layout and the problem solves itself.
If you use one layout for both, wrap it in the guest directive:
@guest
<script src="https://bot.allinaa.com/widget.js" data-bot-id="your-bot-id" defer></script>
@endguest
The assistant's page reading already skips private path segments such as account and checkout paths, so it will not read a page of somebody's data even where the widget is present. Keeping it off those routes entirely is the simpler rule. See where to put the chat widget.
If you have a Content-Security-Policy
An application with a strict policy needs the widget's origin allowed in script-src, and in connect-src for the requests it makes back. If the bubble does not appear and the browser console shows a policy violation, that is the cause - not a bad paste. Add https://bot.allinaa.com to both directives and reload.
One thing you do not need to build
Inquiry notifications are sent by Allinaa, so you need no mail job, no queue worker and no webhook endpoint in your application to receive them. If you would rather have the data in your own database, export the inquiries as CSV from the cabinet - there is no inbound integration to write and nothing to keep in sync. That is worth knowing before somebody on your team plans a week of work.
Check it worked
- Load a public page as a guest in a private window and confirm the bubble appears.
- Sign in and confirm it is absent, if that is what you chose.
- View source and check the
data-bot-idattribute holds your real id and is not empty. - Ask the assistant something about the page you are on, and check the answer is about the right page.
See install troubleshooting and the launch checklist.