Server sources

Server sources accept HTTP requests containing walkerOS events and forward them to the collector. Choose based on your deployment environment.

Available sources

Source	Platform	Use Case
Express	Node.js	Standalone server or existing Express app
Fetch	Edge/Serverless	Cloudflare Workers, Vercel Edge, Deno, Bun
AWS Lambda	AWS	API Gateway, Lambda Function URLs
GCP Cloud Functions	Google Cloud	Cloud Functions HTTP triggers
AWS SQS	AWS	Queue consumer, decoupled ingestion
Google Pub/Sub	Google Cloud	Pull subscriber or push webhook

Choosing a source

Express - Best for traditional Node.js deployments, Docker containers, or when you need full control over the HTTP server.

Fetch - Best for edge computing and serverless platforms that support the Web Standard Fetch API.

AWS Lambda - Best for AWS-native deployments with API Gateway or Lambda Function URLs.

GCP Cloud Functions - Best for Google Cloud deployments using Cloud Functions.

Common features

Server sources come in two shapes, and the shared features differ by shape.

HTTP sources (Express, Fetch, AWS Lambda, GCP Cloud Functions) receive inbound requests and all provide:

• JSON event ingestion (POST), with one shared event envelope
• Pixel tracking (GET with 1x1 GIF response)
• CORS support (configurable)
• Health checks (liveness/readiness endpoints)
• One shared request scope, so a config.ingest mapping resolves the same on each of them

Queue consumers (AWS SQS, Google Pub/Sub pull) read from a queue instead of serving requests. They have no HTTP surface, so none of the request-shaped features above apply, and config.ingest does not either: there is no request to adapt. Retries and dead-lettering stay with the queue.

Producer acknowledgement

Every server source tells its producer what happened to an event from the push result, with one rule:

Push result	HTTP sources	SQS and Pub/Sub pull	Pub/Sub push
Delivered, queued, skipped	200	ack	200
Failed, a resend could fix it (retryable)	500, or 207 for the failed events of a batch	nack	500
Failed, a resend cannot fix it	200, acknowledged	ack	200
Invalid input	400	ack, counted as rejected	400

A deterministic failure is acknowledged on purpose: resending the message would fail the same way and loop. It is visible in the destination's failed counter, its dead-letter queue and one ERROR line per cause and minute. A batched event answers queued, so the producer is acknowledged when the event is queued; a failed flush is reported but the message is not redelivered. The HTTP body never names a destination or quotes a step's error.