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.

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)

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!

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

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.

When something goes wrong

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.

Updated on: 21/09/2026