Skip to main content
The Klaviyo extension uses two Cloud Tasks queues to process work asynchronously. Queueing keeps webhook endpoints fast and responsive, lets the integration absorb traffic spikes, and provides automatic retries when downstream APIs are temporarily unavailable.

​
The two queues

When the extension is installed, two queues are provisioned per tenant: The exact queue names follow the task_queue_name setting on the tenant and the configured namespace (defaulting to klaviyo).

​
Why queues matter

  • Fast webhook responses: When Klaviyo or Omneo POSTs to the extension, the request is acknowledged within milliseconds. The actual sync work is deferred to the queue, so the calling system is never blocked.
  • Automatic retries: If Omneo or Klaviyo is briefly unavailable or rate limited, the queued task retries with exponential backoff until it succeeds or hits the configured retry ceiling.
  • Batching and ordering: Events for the same profile can be combined and processed together (for example, multiple Klaviyo system webhook events arriving close together are merged into a single Omneo update).
  • Back-pressure: During traffic spikes (large list imports, bulk profile changes) the queues smooth out load so neither Omneo nor Klaviyo is overwhelmed.

​
How it works at a high level

  1. A webhook or target hits the extension.
  2. The extension performs only the minimum validation (auth, tenant lookup) before enqueuing a task on the appropriate queue.
  3. Cloud Tasks delivers the task back to the extension’s worker endpoint at a controlled rate, with a fresh Google-issued auth token attached.
  4. The worker runs the actual sync job (profile upsert, metric send, system webhook processing, etc.).
  5. Failures are retried; permanent failures are logged for review.
You do not need to interact with these queues directly. They exist behind the scenes to keep the integration reliable and scalable.