Skip to main content
Your assistant can look things up the moment a customer asks. For example, whether something is in stock, or where an order is. It looks in a system your business already uses. There’s nothing to build, and it works on every plan. Setting it up needs a few technical details about that system. If someone else built it or runs it for you, ask them to help with the first step.

​
Connect a check

A check is one thing your assistant can look up, like stock or an order. You add the check, test it, then choose what your assistant may tell customers.
1

Add a request

On your assistant’s Actions tab, add the details Baza needs to ask your system. A developer usually does this part.
2

Test it

Run it once and see what comes back.
3

Pick what it may share

Choose the information your assistant may tell customers. Everything else stays private.
Each check is an HTTP request to an API you already have: GET or POST, with its key. The fields your API returns are listed under What it may share.

​
What customers see

Your assistant first says what it’s checking, like a person would: “Let me check if that’s in stock”. Then it answers in a second message. Turn on Show items as cards to show products under the answer, with a picture, price and stock.

​
Records about one customer

Some checks are about one customer, like their order. For these, Baza passes on only the records that match that customer: their phone number together with a reference, such as an order number. Each assistant has its own checks, up to 20 different ones.

​
What the test does

You can switch a check on only after its test passes. Until then, it shows Needs a test.
1

Fill in real details

Use details your system really has, like a real product or order number. For a check about one customer, choose where to pretend the customer is: on your website or chat page, or on WhatsApp with a confirmed number.
2

Run test

Baza asks your system exactly as it would for a real customer’s message.
3

Tick what it may share

The information your system sends back appears under What it may share. Tick what your assistant may tell customers. Anything you leave unticked never reaches your assistant.
The result tells you what happened:
  • How fast your system answered. Or that nothing matched the details you used: try details your system has on record, so you can see what it sends back.
  • If your system sends back more than 20 results, your assistant reads only the first 20. Ask your developer to make the check ask only for what the customer wants.
  • For a check about one customer, Baza also tries another customer’s details. Your system must send nothing back for them. Until it does, you can’t switch the check on. This stops one customer seeing another customer’s records.
  • On a check that isn’t about one customer, anyone can see the answers. If some information there looks like a person’s email or phone number, leave it unticked, or make the check about one customer.
Open What Baza sent and What came back to see exactly what Baza asked and what your system answered. Your developer will find these useful. If a test fails later, the check switches off until a test passes again.
What Baza sent and What came back show the exact request and response. When more than 20 records come back, add a query parameter so the request asks for only what the customer wants.

​
Using your key

A key works like a password. It shows your system that a question really comes from Baza. A developer usually sets this up. Most checks use your system’s own key. Some older setups use Your own endpoint instead, with a key that Baza makes for you.
An HTTP request uses your API’s own key, which you add to the request.With Your own endpoint, your system answers in Baza’s format, at an address you give Baza. Its address and key are in the ⋯ menu next to Your own endpoint, under Address and key.
1

Make a key

Press Make a key. It starts with bzk_ and is shown only once, so copy it now and paste it into your system.
2

Check every request

Your system should refuse any request whose Authorization header isn’t Bearer followed by this key.
The test sends a request with a wrong key too, which your system should refuse. A check about one customer can’t be switched on until it does.
Make a new one stops the current key straight away. Lookups fail until the new key is pasted into your system. Do it if the key may have leaked, or if someone who had it has left.