Back to Technical Blog & Case Studies
API Middleware•8 min read•2026-08-10

Building Sub-100ms Webhook Middleware for GoHighLevel V2 API

Learn how to engineer high-throughput Node/TypeScript middleware that handles OAuth token refreshes and queues thousands of GHL webhook events without dropped leads.

ErrorNix Systems EngineeringLead GHL V2 API Architect

Building Sub-100ms Webhook Middleware for GoHighLevel V2 API

GoHighLevel (GHL) V2 API is the backbone of enterprise CRM engineering. When managing hundreds of sub-accounts, relying on direct client-side webhooks or simple Zapier triggers creates race conditions, dropped contact tags, and rate limit errors.

In this deep-dive guide, we will break down how to architect custom serverless middleware connecting GHL webhooks with your internal backend databases.

Why GHL Webhook Middleware is Mandatory for Scaling Agencies

When marketing agencies scale past 50 sub-accounts, standard webhook integrations fail for three reasons:

  • •OAuth Token Expiration: GHL V2 API access tokens expire every 24 hours. Without automated refresh token rotation queues, API requests silently fail.
  • •Burst Load Concurrency: High-volume ad campaigns can trigger 500+ webhooks in a 5-second window. GHL rate limits will drop unqueued payload requests.
  • •Field Mapping Ambiguity: Custom fields in GHL sub-accounts often get renamed or duplicated during snapshot updates.
TypeScript / Architecture SnippetErrorNix Engine
import { GHLClient } from '@errornix/ghl-sdk';

export async function processWebhook(payload: Record<string, any>) { const ghl = new GHLClient({ locationId: payload.locationId, token: await getValidOAuthToken(payload.locationId), });

// Execute atomic GHL V2 contact update with sub-100ms latency return await ghl.contacts.upsert({ email: payload.email, phone: payload.phone, customFields: payload.customFields, }); } ```

Key Architecture Principles for Sub-100ms Latency

1. Redis/Upstash Webhook Ingestion Queue Instead of processing payloads synchronously inside the HTTP handler, return a 200 OK immediately and push the raw payload to an asynchronous Redis queue.

2. Idempotent Deduplication Keys Generate an MD5 hash of `locationId + contactId + timestampWindow` to ensure duplicate webhooks fired by GHL triggers do not trigger duplicate SMS campaigns.

3. Automated OAuth Token Renewal Middleware Store access tokens and refresh tokens in encrypted Redis keys with a TTL matching token expiration. Automatically request new tokens 30 minutes prior to expiration.