Collect emails in one click. Then stop clicking.

What you can put on autopilot

The API is the same engine the dashboard runs on, without the dashboard. Four things teams wire up most often:

Before you start

• n8n — cloud or self-hosted. Any recent version; nothing here uses a community node.
• A GoLeadX account on the Scale plan — API access is not included on Basic or Pro.
• An API key — created in the dashboard under Billing → API keys, shown once.
• Somewhere to put the results — a Google Sheet, a CRM, or your sending tool.

The shape of the workflow

Three calls, in a loop. A search returns an id straight away, you poll that id until it reports done, and then you read the rows off the finished job.

Schedule Trigger
      │
      ▼
HTTP Request  ──▶  POST /api/v1/search        → { id, status, poll }
      │
      ▼
    Wait (30s) ◀───────────────┐
      │                        │
      ▼                        │
HTTP Request  ──▶  GET {{ $json.poll }}        → { status, leads[] }
      │                        │
      ▼                        │
     IF  status = done ? ──no──┘
      │ yes
      ▼
Split Out (leads)  ──▶  Filter (emailStatus)  ──▶  CRM / Sheet / Sequence

The loop is the part worth getting right. A real search runs for minutes, and holding an HTTP connection open that long fails at whatever proxy sits between n8n and us — which is why the API never asks you to.

Building it, node by node

1. 01

   Create an API key

   Open the GoLeadX dashboard, go to Billing → API keys, and create one. It is shown once and stored only as a hash, so copy it before closing the panel. API access is on the Scale plan.

2. 02

   Add a Header Auth credential in n8n

   In n8n, create a Generic Credential Type → Header Auth credential. Name: Authorization. Value: Bearer glx_live_… — the key you just copied. Every node in the workflow reuses this one credential.

3. 03

   Trigger the workflow

   Use a Schedule Trigger for a recurring list — weekly on Monday at 07:00 is a common choice — or a Webhook node if another system decides when a search should run.

4. 04

   Start the search

   HTTP Request node, POST to https://goleadx.com/api/v1/search with your queries, locations and sources as JSON. It returns an id immediately rather than holding the connection open, so nothing times out.

5. 05

   Wait, then poll until it is done

   A Wait node of 30 seconds, an HTTP Request node that GETs the poll URL from the previous response, and an IF node that loops back to Wait while status is not done. Most searches finish inside a couple of minutes.

6. 06

   Split and filter to deliverable addresses

   Split Out on the leads array, then a Filter node keeping emailStatus equal to valid or risky. Sending to invalid addresses is what costs a sender reputation, so this node is not optional.

7. 07

   Deliver the leads

   Push each row wherever it belongs: an HTTP Request node into your CRM, the Google Sheets node for a shared list, or your sending tool's node to enrol contacts in a sequence directly.

The request body

Sent by the first HTTP Request node. Every keyword runs against every location, so three keywords across four cities is twelve searches in one call.

{
  "queries": ["dental clinics", "orthodontists"],
  "locations": ["Miami", "Orlando", "Tampa"],
  "sources": ["google_maps", "web_search"],
  "maxResults": 200,
  "verifyEmails": true,
  "enrich": true
}

What comes back while it runs

Rows appear in leads during the run, not only at the end, so a workflow that wants to start sending early can read them before status flips to done.

{
  "id": "9f2c…",
  "status": "running",
  "progress": { "found": 128, "withEmail": 54, "verified": 41 },
  "leads": [
    {
      "name": "Northside Dental Studio",
      "email": "hello@example.com",
      "emailStatus": "valid",
      "phone": "+1 305 555 0142",
      "website": "https://example.com",
      "city": "Miami",
      "source": "google_maps"
    }
  ]
}

The filter that matters

Every address carries a verdict. Keep valid and risky — role addresses such as info@ resolve correctly and are graded risky rather than bad — and drop invalid before anything sends.

{{ $json.emailStatus === "valid" || $json.emailStatus === "risky" }}

Make, Zapier, or your own code

None of this is specific to n8n. It is bearer authentication and JSON over HTTP, so any tool that can make three requests can run the same workflow.

# 1 — start
curl -X POST https://goleadx.com/api/v1/search \
  -H "Authorization: Bearer glx_live_xxxx" \
  -H "Content-Type: application/json" \
  -d '{"queries":["dental clinics"],"locations":["Miami"],"sources":["google_maps"]}'

# 2 — poll, until "status": "done"
curl https://goleadx.com/api/v1/search/9f2c… \
  -H "Authorization: Bearer glx_live_xxxx"

In Make, use the HTTP module with a repeater and a sleep between polls. In Zapier, Webhooks by Zapier covers the same three calls, though its step limits make long polls awkward — a schedule that re-checks a stored job id works better there.

When it does not work

Questions