Code Destination

The code destination is a built-in, platform-agnostic destination that executes custom JavaScript code strings. It provides a lightweight alternative to tag managers like GTM, allowing you to run arbitrary code in response to events without external dependencies.

Where this fits

Code is a built-in destination in the walkerOS flow:

Executes custom JavaScript code strings on events, loads external scripts dynamically, and acts as a lightweight tag manager replacement.

Configuration

Use code: true to enable the built-in code destination:

Loading...

Script Loading

Load external scripts during initialization - useful for tag management:

Loading...

Scripts are injected in parallel with async="true". The collector only handles injection - loading, errors, and execution are managed by the browser. For advanced loading patterns (sequential loading, onload callbacks), use custom init code.

Configuration reference

Settings

Property	Type	Description
scripts	string[]	URLs of external scripts to inject on init
init	string	Code to run once when the destination initializes
on	string	Code to run on lifecycle events (consent, etc.)
push	string	Default code to run for each event
pushBatch	string	Default code to run for batched events

Mapping

Event-specific code can override settings via mapping:

Property	Type	Description
push	string	Code to run for this specific event
pushBatch	string	Code to run for batched events

Context variables

Each code string has access to specific variables:

init

• context.collector - The collector instance
• context.config - Destination configuration
• context.env - Environment variables
• context.logger - Scoped logger instance

push

• event - The WalkerOS event object
• context.collector - The collector instance
• context.config - Destination configuration
• context.data - Transformed event data (from mapping)
• context.env - Environment variables
• context.logger - Scoped logger instance
• context.mapping - The event mapping rule

pushBatch

• batch.key - The batch key (event name)
• batch.events - Array of events in the batch
• batch.data - Array of transformed data
• batch.entries - Per-event entries, each carrying { event, ingest?, respond?, rule?, data? }. Read this when you need the per-event ingest or respond (for HTTP responses, per-event request IDs, etc.). batch.events and batch.data are derived views kept for backward compatibility.
• context.collector - The collector instance
• context.config - Destination configuration
• context.env - Environment variables
• context.logger - Scoped logger instance
• context.mapping - The event mapping rule (representative entry's rule)

Batch scheduling

A destination can cap how large or how old a batch may grow before it is flushed. Configure via config.batch (bare number = legacy debounce wait window):

{
  config: {
    batch: { wait: 1000, size: 1000, age: 30000 },
    // ...
  }
}

• wait (ms) - Debounce window. The timer resets on every push.
• size - Hard count cap. Flushes immediately at this many events. Default 1000 when batching is enabled.
• age (ms) - Hard age cap since the first entry of the current window. Forces a flush even when pushes keep arriving. Default 30000.

Without size/age the batch can grow unbounded under sustained load (the debounce timer keeps resetting). Defaults are conservative; raise them only when you understand your destination's batch-size limits.

Failure handling

If pushBatch throws (or returns a rejected Promise), the entire batch is routed to the destination's dlq (dead-letter queue) and status.destinations[id].failed is incremented by the batch size. Per-item retry logic is the destination SDK's responsibility (BigQuery, Kafka, HubSpot each have their own backoff semantics). The collector never drops batch failures silently.

on

• type - The event type ('consent', 'ready', etc.)
• context.collector - The collector instance
• context.config - Destination configuration
• context.data - Event-specific data
• context.env - Environment variables
• context.logger - Scoped logger instance

Examples

Basic logging

Loading...

API calls

Loading...

Consent handling

Loading...

Event-specific overrides

Use mapping to override the default push code for specific events:

Loading...

Batched events

Loading...

Error handling

All code execution is wrapped in try-catch blocks. Errors are logged using the destination's scoped logger and don't affect other destinations or event processing.

Loading...

Security considerations

The code destination uses new Function() to execute code strings. This is similar to eval() and should only be used with trusted code. Never execute user-provided code strings directly.

For production environments, consider:

• Only using code strings defined in your source code
• Validating and sanitizing any dynamic configuration
• Using Content Security Policy headers where appropriate