BigCommerce + Memtro

Only when you ask, and only what it has been granted: change an order's status, staff notes or customer message (a status change may email the shopper, per the store's notification settings); create a shipment for items on an order, with tracking; BigCommerce emails the shopper; issue a refund on an order to the original payment method (moves money); capture an authorised payment on an order (takes money); void the payment on an order (releases the authorisation, cannot be undone); create an order by hand (no order email is sent); archive an order; create a product; change a product's name, price, stock, visibility or description (live on the storefront at once); delete a product, permanently; create a customer; change a customer's name, email, phone, company, notes or group. Every other tool reads, searches or lists. The Connections page labels the tools that act, an administrator grants each one by name to the teams that may use it, and a personal connection acts only after its owner allows it.

A personal connection serves only your own requests. A shared connection serves the organisation: everyone, or only the teams an admin chooses. Admins can always add shared connections; other members need the permission.

Credentials are encrypted at rest. Tool results are cached briefly so agent loops do not repeat identical calls, and the facts the model extracts are saved to your organisation's memory with provenance (system, record and link) so they can be checked and superseded. An hourly sync anchors recently changed BigCommerce records into memory as entities.

Store hash and access token. In BigCommerce open Settings → Store-level API accounts → Create API account and tick Orders, Products, Customers and Information & Settings read-only. For the actions give Orders, Products or Customers the modify level for the ones you want to allow.

Yes. Turn events on in the connection's Events tab on the Connections page, choose the kinds you want, and Memtro registers its address with BigCommerce for you. A job set to start "When an event arrives" then runs once for each matching event, with the event as its input. The run treats the event as outside data, never as instructions, and anything the run remembers is kept as unverified.