This post covers both. The examples use placeholders, so swap in the values your widget gives you.

The snippet

A typical embed looks like this:

<script
  src="YOUR_WIDGET_SCRIPT_URL"
  data-bot-id="YOUR_BOT_ID"
  defer></script>

Two things matter. defer stops the widget from blocking your page while it loads. And the snippet should go just before </body>, or in the site builder's "footer code" box, so your own content loads first.

Shopify

1. In the admin, go to Online Store > Themes.
2. On your live theme, open the menu next to Customize and choose Edit code.
3. Open layout/theme.liquid.
4. Paste the snippet on the line just above </body> and save.

Theme updates can replace theme.liquid, so keep a note of the change. Shopify's checkout pages do not load your theme layout, so don't expect the bubble to show there.

WordPress

For a classic theme, the cleanest way without an extra plugin is a small hook in your child theme's functions.php:

add_action( 'wp_footer', function () {
    echo '<script src="YOUR_WIDGET_SCRIPT_URL" data-bot-id="YOUR_BOT_ID" defer></script>';
} );

Use a child theme. If you edit the parent theme, the next theme update wipes the change. If you already use a header-and-footer code plugin, its footer box works too.

Webflow

1. Open Site settings > Custom code.
2. Paste the snippet into Footer code.
3. Save, then publish the site. Webflow only adds custom code to the published site, not the Designer preview.

To show the bubble on one page only, use that page's own settings (Custom code, before </body> tag) instead.

Wix

1. Go to Settings > Custom code (under Advanced).
2. Click Add custom code and paste the snippet.
3. Choose All pages, set the place to Body - end, and apply.

Wix only runs custom code on a published site with a connected domain, so test it on the live address, not in the editor.

Keep it to your own domain

Your snippet is public. Someone can copy it onto their own site and start using your question allowance. The check that matters runs on the widget's server, not in the browser.

When the widget calls its API from a page, the browser sends an Origin header naming the site. The server compares it with an allowlist:

// Each entry is a full origin: scheme plus host, no path.
const ALLOWED_ORIGINS = new Set([
  process.env.SITE_ORIGIN,      // your bare domain
  process.env.SITE_ORIGIN_WWW,  // the same domain with www in front
]);

function isAllowedOrigin(req) {
  const origin = req.headers.origin;
  return typeof origin === 'string' && ALLOWED_ORIGINS.has(origin);
}

// in the handler
if (!isAllowedOrigin(req)) {
  return res.status(403).json({ error: 'origin not allowed' });
}

Three details catch people out:

• List every form of your address. Your bare domain and its www version are different origins, and so are the plain and secure (TLS) versions of each.
• Don't trust a check in the browser. A widget script that reads window.location.hostname and refuses to start is easy to remove from a copied page.
• The Origin header stops browsers, not scripts. A script outside a browser can send any header it likes, so add a rate limit per bot as well. An allowlist plus a limit on questions per minute covers both the copied snippet and the script.

Check it works

After publishing, open your live site in a private window and ask the bubble a question your pages answer, such as "Are you open on Saturday?". Then paste the same snippet into a local HTML file and open it: the widget should refuse to answer there. If it answers in both places, your allowlist is too wide.

I work on TailGPT (https://tailgpt.tailwebs.com/?utm_source=hashnode.com&utm_medium=article&utm_campaign=adding-a-chat-agent-with-one-script-tag-on-shopify-wordpress&utm_content=adding-a-chat-agent-with-one-script-tag-on-shopify-wordpress), a website AI agent that installs this way: one script tag, no plugin, loading only on your own domain, with a questions-per-minute limit. The steps above work the same for any widget that gives you a script tag.

If your site builder isn't covered here, look for a box called "footer code", "custom code" or "before </body>". That's almost always where the snippet goes.

I work on Fincurry, a family group and personal expense tracker that syncs in real time across the family and lets you split bills and settle up, so I think about this problem a lot. To be clear: the code below is a general illustration of the technique in plain JavaScript. It is not how Fincurry is built, and it does not describe its database or sync setup.

The idea fits in four rules:

1. Store operations, not the current state.
2. Give every operation a unique id and a logical clock, so every phone sorts them the same way.
3. Merge per field, so edits to different fields never fight.
4. Recompute balances from the operations instead of storing running totals, and make settle-up an operation with its own id, so a repeated sync cannot count it twice.

Step 1: an operation log with a logical clock

Wall clocks on phones drift, so we do not trust them for ordering. A Lamport counter is enough here: each device increases its counter for every operation it makes, and jumps ahead whenever it sees a higher counter from another device. Ties are broken by the device name, so the order is the same everywhere.

// sync.js
'use strict';

function createDevice(device) {
  let counter = 0;
  let seq = 0;
  return {
    observe(ops) {
      for (const op of ops) counter = Math.max(counter, op.counter);
    },
    op(fields) {
      counter += 1;
      seq += 1;
      return { id: `${device}:${seq}`, device, counter, ...fields };
    },
  };
}

function compareStamp(a, b) {
  if (a.counter !== b.counter) return a.counter - b.counter;
  if (a.device === b.device) return 0;
  return a.device < b.device ? -1 : 1;
}

Step 2: merge logs by id

Merging is a set union keyed by the operation id, then a sort. Receiving the same operation twice changes nothing, which is exactly what you want when a flaky connection retries an upload.

function mergeLogs(...logs) {
  const byId = new Map();
  for (const log of logs) for (const op of log) byId.set(op.id, op);
  return [...byId.values()].sort(compareStamp);
}

Step 3: fold operations into expenses, one field at a time

Each edit is a set operation on one field of one expense. Folding the sorted log means the latest write wins per field, not per expense. So the amount fixed on the train and the new split made at home both survive. Amounts are whole minor units (paise, cents) so no floating point creeps into the totals. Deleting is just setting deleted to true.

function foldExpenses(ops) {
  const expenses = new Map();
  for (const op of ops) {
    if (op.type !== 'set') continue;
    const current = expenses.get(op.expenseId) || {};
    expenses.set(op.expenseId, { ...current, [op.field]: op.value });
  }
  return expenses;
}

Step 4: recompute balances, and treat settle-up as an operation

A running total such as "Ravi owes 1,200" goes wrong the moment two offline edits arrive in a different order. Recomputing from the merged log always gives the same answer on every phone. A positive balance means the person is owed money. An equal split hands out the leftover minor units in a fixed order, so the balances always add up to zero.

function balances(ops) {
  const totals = {};
  const add = (person, amount) => {
    totals[person] = (totals[person] || 0) + amount;
  };
  for (const e of foldExpenses(ops).values()) {
    if (e.deleted || !e.amount) continue;
    const people = [...e.splitAmong].sort();
    const base = Math.floor(e.amount / people.length);
    let rest = e.amount - base * people.length;
    add(e.paidBy, e.amount);
    for (const person of people) {
      const extra = rest > 0 ? 1 : 0;
      rest -= extra;
      add(person, -(base + extra));
    }
  }
  for (const op of ops) {
    if (op.type !== 'settle') continue;
    add(op.from, op.amount);
    add(op.to, -op.amount);
  }
  return totals;
}

module.exports = { createDevice, mergeLogs, foldExpenses, balances };

Step 5: prove it with node:test

// sync.test.js
'use strict';
const { test } = require('node:test');
const assert = require('node:assert');
const { createDevice, mergeLogs, foldExpenses, balances } = require('./sync');

function createGroceries(device) {
  return [
    device.op({ type: 'set', expenseId: 'groceries', field: 'amount', value: 2400 }),
    device.op({ type: 'set', expenseId: 'groceries', field: 'paidBy', value: 'asha' }),
    device.op({ type: 'set', expenseId: 'groceries', field: 'splitAmong', value: ['asha', 'ravi'] }),
  ];
}

test('offline edits to different fields both survive', () => {
  const asha = createDevice('asha');
  const ravi = createDevice('ravi');
  const shared = createGroceries(asha);
  ravi.observe(shared);

  const ashaOffline = [asha.op({ type: 'set', expenseId: 'groceries', field: 'amount', value: 3000 })];
  const raviOffline = [ravi.op({ type: 'set', expenseId: 'groceries', field: 'splitAmong', value: ['asha', 'ravi', 'meera'] })];

  const merged = mergeLogs([...shared, ...ashaOffline], [...shared, ...raviOffline]);
  const expense = foldExpenses(merged).get('groceries');
  assert.strictEqual(expense.amount, 3000);
  assert.deepStrictEqual(expense.splitAmong, ['asha', 'ravi', 'meera']);
  assert.deepStrictEqual(balances(merged), { asha: 2000, ravi: -1000, meera: -1000 });
});

test('a conflict on the same field ends the same way on every phone', () => {
  const asha = createDevice('asha');
  const ravi = createDevice('ravi');
  const shared = createGroceries(asha);
  ravi.observe(shared);

  const a = [asha.op({ type: 'set', expenseId: 'groceries', field: 'amount', value: 2500 })];
  const r = [ravi.op({ type: 'set', expenseId: 'groceries', field: 'amount', value: 2600 })];

  const onAshaPhone = foldExpenses(mergeLogs([...shared, ...a], r)).get('groceries');
  const onRaviPhone = foldExpenses(mergeLogs([...shared, ...r], a)).get('groceries');
  assert.strictEqual(onAshaPhone.amount, onRaviPhone.amount);
});

test('a settle-up received twice is counted once', () => {
  const asha = createDevice('asha');
  const ravi = createDevice('ravi');
  const shared = createGroceries(asha);
  ravi.observe(shared);
  const settle = ravi.op({ type: 'settle', from: 'ravi', to: 'asha', amount: 1200 });

  const merged = mergeLogs([...shared, settle], [settle], [...shared, settle]);
  assert.deepStrictEqual(balances(merged), { asha: 0, ravi: 0 });
});

Run it with node --test. All three tests pass with no dependencies.

What this does not solve

Same-field conflicts lose one value. Last writer wins is predictable, but one person's amount quietly disappears. For money fields it is often kinder to keep both operations, show the expense as "edited on two phones" and let a person pick. The log already has everything you need for that, because nothing is overwritten.

Two people can both tap settle up. If both members record the same payment while offline, you get two operations with different ids, and the id check cannot catch that. A simple guard is to flag any settle-up that pushes a balance past zero, and ask instead of guessing.

Logs grow. Once every device in the group has seen everything up to some counter, you can fold that part of the log into a snapshot and keep only the newer operations.

The main lesson for me: when the data is money shared by a household, don't store totals, store what happened. Totals you can always work out again. A lost edit you can't get back.