> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.wiremo.co/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# GLocal | API Integration

# API Integration

## What the API is for
**The API connects GLocal to your own systems, so the work happens automatically instead of by hand in the dashboard.** 
Anything that can talk to a web API can drive it — your website or booking system, your CRM, an internal tool, an automation platform, or an AI agent.

It works in two directions, matching the two tabs on the page:
1. **Send review requests in.** 
 — Your system passes a customer to GLocal, and GLocal enrols them in the review-request sequence — the timing, the follow-ups, the filtering and the unsubscribe handling all continue as configured. 
2. **Pull reviews out.** 
 — Your Google reviews are read out of GLocal and used wherever you need them: displayed on your own site, fed into a reporting dashboard or data warehouse, passed to an AI system to summarize or draft replies, or watched so an alert fires the moment a one-star review arrives.

> **You will need a developer**
> This is the one part of GLocal that is not point-and-click. Everything on this page you can do yourself — creating the key, checking the logs — but connecting your own system to GLocal is work for whoever builds or maintains it. Your part is to create the key, hand it over safely, and check afterwards that requests are arriving.
---

## 1. Decide which API you need
**Open API Integration in the left sidebar and you will find two tabs. They are two separate APIs, with separate keys, and you may well only need one.**

|  | Review Requests | Reviews |
| ---- |
| **Use it to** | Add customers so they are asked for a review | Read your Google reviews out of GLocal |
| **Access** | Read and write | Read-only |
| **Typical job** | Your booking system tells GLocal a job is finished | Your website shows your latest reviews |

|| Keys from the two tabs are not interchangeable
A key made on one tab will not work on the other. It is refused with a 401 Unauthorized and no further explanation, which sends people hunting for a typo that is not there.
If your developer reports that the key is being rejected and they are certain it was copied correctly, check which tab you created it on. It is the single most common cause.

> **A key only ever sees one business profile**
> Every key is tied to the business profile it was created under, and can only read or touch that profile’s data. That is what makes it safe to hand to a developer, or to a third party building an integration for you — they cannot reach your other businesses with it.
---

## 2. Create your key

### Step 1 — Open the right tab
Go to **API Integration** in the left sidebar and choose the tab you need: **Review Requests** **(Pin 1)** to send requests, **Reviews** **(Pin 2)** to read them.
### Step 2 — Click Create key
The button sits at the top of the tab. **(Pin 3)**
### Step 3 — Name it after the system that will use it
Not “key 1”. Something like *Website booking form* or *HubSpot sync*. In a year, when you are deciding whether a key is still needed, the name is the only thing that will tell you.
### Step 4 — Copy the key immediately
The key is shown in full **exactly once**, at the moment it is created. Copy it before you close the dialog. **(Pin 4)**

|| A lost key cannot be recovered
Once the dialog is closed the key is masked forever — GLocal will not show it again, and support cannot retrieve it. If you lose it, revoke it and create a new one. That is not a problem, as long as you remember to update whatever system was using the old one.

### Step 5 — Save it
The button \*\*I've saved it (Pin 5) saves the key and closes the creation dialog. **Press it only after successful copying the key!**

![](https://storage.crisp.chat/users/helpdesk/website/-/7/f/2/f/7f2f2b9a81bb9000/01-api-keys_ak1txo.png)

||| Keep the Key safe!
An API key is a password. Anyone who has it can read your reviews and, on a Review Requests key, create customers and send emails in your name.

### Best safety practices
* **Store it in a password manager or a secret store** — never in a shared document, a spreadsheet or a chat message that stays searchable.
* **Never put a key in a web page.** Anything in front-end JavaScript is readable by every visitor. Calls to GLocal must be made from your server. 
* **Use one key per system.** When a tool is retired or a contractor leaves, you revoke that one key without disturbing anything else.
* **Revoke immediately if you suspect it has leaked.** Creating a replacement takes a minute.
---

## 4. What to give your developer
**Along with the key, these are the things they need to know:**
You do not have to understand them — passing them on saves a round of questions.

### Where to send requests
| API | Base URL |
| ---- |
| Review Requests | https://glocal.wiremo.co/api/public/v1/customers |
| Reviews | https://glocal.wiremo.co/api/public/v1/reviews |
The key travels as a Bearer token on every request:
```
Authorization: Bearer {your_api_key}
Content-Type: application/json
```

> **Full technical documentation**
> Every endpoint, with request and response examples, error codes and a worked end-to-end example, is in the developer reference. Send that to whoever is building the integration — this article covers your side of the job, not theirs.


### Four behaviours that catch people out
* **Creating a customer is all it takes.** Adding a customer through the API enrols them in the review request sequence automatically. There is no second call to make.
* **Customers are deduplicated by email.** Sending someone who already exists updates them instead of creating a duplicate, so the same customer can safely be sent twice.
* **A successful response does not mean every customer was added.** The reply carries an `errors` list, per row. Code that only checks the HTTP status will silently drop customers.
* **The Reviews API allows 60 requests a minute.** Large syncs should page through in batches with a pause, not fire requests in parallel.
---

## 5. Check that it is working
Once the integration is live, **API Request Logs** shows what it is actually doing. It records requests made by outside systems using a key — not your own clicking in the dashboard.
Find it under **your name at the bottom of the left sidebar**, then **API Request Logs**. Go there whenever something is not behaving, because it answers the first question: *did the request even arrive?*

### Narrowing the list
* **Business Profile** (Pin 1​) — one business at a time. The dropdown lists every profile, not only those with API activity, so an empty result means that profile has had no API calls at all.
* **Status** (Pin 2​) — successes alone, or failures alone.
* **IP** (Pin 3​) — one calling system at a time, when several use the API.
* **Date** (Pin 4​) — today, back to a custom range.
Each row shows Date, Profile, Method, Path, Status and IP (Pin 5​). **Method** is the kind of request — `GET` reads data out, `POST` sends data in. **Path** says which API was called. **IP** is the server that called, so you can tell one integration from another, or spot one you do not recognise.

### Reading the Status column
* **2xx** — it worked. `201` on a customer call means the customer was added and enrolled.
* **4xx** — GLocal refused the request because something about it was wrong. `401` means the key was missing, wrong, revoked, or made on the other tab.
* **5xx** — the request was fine but GLocal failed to complete it.
> **The quickest way to tell whose problem it is**
> Filter to **4xx** and you see the requests your integration got wrong — your developer’s side. Filter to **5xx** and you see the requests GLocal got wrong — ours; send a screenshot to support. One glance settles which side to work on, before anyone starts reading code.

![](https://storage.crisp.chat/users/helpdesk/website/-/7/f/2/f/7f2f2b9a81bb9000/02-api-request-logs_1xb42qr.png)


### When something goes wrong
| What you see | What it usually means |
| ---- |
| Every request refused, key looks correct | The key was created on the other tab. Review Requests and Reviews keys are not interchangeable. |
| It worked yesterday, not today | The key was revoked, or someone created a replacement and retired the old one. |
| Customers added, but no emails going out | Check the customer in the Customer List — they may be unsubscribed, paused, or have already left a review. |
| Some customers arrive, some do not | The integration is not reading the per-row errors list. Usually duplicates or unsubscribed customers. |
| Nothing at all in API Request Logs | Requests are not reaching GLocal. The problem is upstream, in the sending system. |
| Rows showing 5xx | GLocal’s side. Screenshot the row and contact support. |
> **Before you contact support**
> Open **API Request Logs**, filter to the profile and the day in question, and screenshot what you see. Whether requests arrived at all, and what GLocal answered, is the first thing anyone will ask.
---

## You’re all set
The API turns GLocal into something your own systems can drive: requests go in from wherever your customers are recorded, reviews come out to wherever you need them. Set it up once and it runs without anyone opening the dashboard.
Two things worth checking now and then: that new customers are still appearing in your **Customer List**, and that **API Request Logs** is not filling with 4xx. A key that quietly stopped working looks exactly like a quiet week.

---