Skip to main content
Altcraft Docs LogoAltcraft Docs Logo
User guide iconUser guide
Developer guide iconDeveloper guide
Admin guide iconAdmin guide
English
  • Русский
  • English
Login
    Getting StartedAdministrator documentationFunctional characteristics
      Technology descriptionarrow
    • Architecture OverviewComponent Description
        Deployment schemesarrow
      • Basic schemeFail-safe schemeTypical Placement in Infrastructure
    System requirements
      Admin Panelarrow
      • Account areaarrow
        • Accountsarrow
        • Account UsersAccount Virtual SendersAccount Database Indexes
        TariffsExternal data configurationLDAPTasksSchedule JobsGlobal Stop ListsWebversion Store Policies
        Settingsarrow
      • Databases
          Accessarrow
        • AdminsAPI tokens
        Notifiers
          MTAarrow
        • Default rulesRetry rulesLock rulesBounce patternsStrategiesKeysISPsPools
      Nodes
        Sendersarrow
      • EmailSMSEvent generatorIntegration with Altcraft Cloud SMTPIntegration with Sendsay
        Reportsarrow
      • Audit JournalData Usage
        Toolsarrow
      • ARF decoderURL decoderSMID decoderLicense
      Platform installationarrow
    • Automatic installationManual installationRunning the platform in a Docker container
      Platform configurationarrow
    • Configuration fileDomain settingsLDAP access configurationSending Email via SMTP relayPixel and push domain configurationCluster and Replication SetupSystem notifications configurationProcesses UNIX sockets configurationHTTPS ConfigurationMigrating from MongoDB Community to Percona ServerAdding sender IP addressesDeduplication request settingsPostgreSQL database for Market dataProxy server settingsKeycloak Integration with AltcraftGetting HTTP service statusesConfiguring MongoDB log rotation
        Configuration of system constants and directoriesarrow
      • Filtering bot actionsDirectory of gender markers
      Custom Channelsarrow
    • Creating a Channel
        Pipelinesarrow
      • MessageScheduleListenerModerateStop
          Pipesarrow
        • HTTP RequestPackUnpackEventerSchedulerSelectorSQLStore SetStore GetLogResultErrorRMQ Publisher
      External Objects (Entities)Templating LanguageSending FilesPresets (Field Sets)DebuggingTechnical Limitations
      Platform maintenancearrow
    • Personnel requirementsPlatform maintenance processesPlatform updatingBackup and recoveryTransferring the platform to a new serverCreating, deleting, and populating tables for statistics in ClickHouseUsing the aktool utilityUsers and directories engaged by the platformPlatform service monitoringProcess and mailing monitoring via Prometheus
      Extraarrow
    • System page customizationSend Message IDClickHouse History Migration GuideInstructions for migrating history to ClickHouseUtility for importing push subscriptions to Firebase projectUtility for importing push subscriptions to Firebase projectENS: настройка интеграции
    Processing HTTP/HTTPS traffic
      Administrator APIarrow
      • Accounts admin apiarrow
        • Restricted accessarrow
        • Account Activation and DeactivationAccount Freeze and Unfreeze
        Get accounts listAdd a new accountDelete the account
        Account usersarrow
      • Update an Existing AccountAdd a new userDelete a userGet a list of usersSending a Welcome Email
        Nodesarrow
      • Synchronize node MTA configurationGet nodes listGet node MTA statusActivate node MTADeactivate node MTA
        Senders admin apiarrow
      • Create or update AKMTA senderGet AKMTA sender informationAssign account to senderGet senders listDelete senderRestore sender
          Sender queuearrow
        • Get sender queue informationHold sender queueRelease sender queueClear sender queue
        Virtual sendersarrow
      • Get virtual senders listGet virtual sender informationCreate virtual senderUpdate virtual senderClone virtual senderDelete virtual sender
    Documentation Archive
  • Custom Channels
  • Pipelines

Pipelines

Pipeline is a chain of data processing elements that describes how a channel interacts with external services. A pipeline is defined as a JSON array and configured on the Pipelines tab when setting up a channel.

Pipe is an element of a pipeline that performs a single specific action: sends an HTTP request, packs data into JSON, writes a log, registers an event, etc. Each pipe has an input and can have one or more outputs. If a pipe has no outputs, the event exits the pipeline.

A complete list of pipes with parameter descriptions and examples is available in the Pipes section.

How a pipeline works​

A pipeline works by sequentially passing an event from pipe to pipe:

  • Each pipe has a unique id, which also serves as its input.
  • The pipe's outputs (outs) specify the id of the next pipe that the event will move to on success (success) or error (error).
  • If an output is not specified, the event exits the pipeline.
  • Data passed to a pipe from the previous pipe is accessible via the $in keyword.
  • The original pipeline data is accessible via $origin.

You can access field values inside a pipe using the templating language.

Flow visualization​

[Pipe 1: Pack] ──success──> [Pipe 2: HTTP Request] ──success──> [Pipe 3: Eventer (deliv)]
│
error
v
[Pipe 4: Eventer (undeliv)]

Each arrow is defined through the pipe's outs: success specifies the next pipe's id on success, error — on error. If an output is not specified, the event exits the pipeline.

Working with array data​

Some channel entity fields can contain array values. This happens in two cases:

  • External Object with List operation — only available for Template and Campaign. The user can select multiple values (e.g., multiple profiles or segments), and the List operation result enters the pipeline as an array.
  • Fields with multiple selection — some field types (e.g., file, image_upload, enum with multi-select option) also return arrays.

If you need to extract a specific value from the array, use indexing via .%<index> (zero-based indexing):

$template.profile.%0.id

This returns the id of the first selected item. To access the second — %1, the third — %2, and so on.

If you need to access the entire array, use the keyword without indexing:

$template.profile

To unpack an array into a repeating structure (for example, when building JSON with multiple attachments), use the $$ prefix. For more details, see the Templating Language section.

Pipe structure​

Each pipe is described as a JSON object with the following fields:

FieldExampleRequiredDescription
id5YesUnique identifier of the pipe in the pipeline. Also serves as its input.
type"log"YesPipe type (determines which action is performed).
params{}NoParameters specific to this pipe type.
outsOutsObjectNoPipe outputs — determine which pipe the event will move to.

Pipe outputs (OutsObject)​

FieldExampleRequiredDescription
success3Noid of the pipe the event will move to on successful execution.
error4Noid of the pipe the event will move to on error.

Parallel processing​

Each pipe in a pipeline processes events in parallel: multiple independent worker processes are spawned for each pipe. The number of workers is configured via the PIPE_WORKER_SIZE parameter in the platform configuration. This allows multiple events for the same pipe to be processed concurrently.

Pipeline example​

Below is an example of a pipeline that builds a JSON request, sends it over HTTP, and depending on the result, registers a delivery or non-delivery event:

[
{
"id": 1,
"type": "pack",
"params": {
"type": "JSON"
},
"outs": {
"success": 2
}
},
{
"id": 2,
"type": "http_request",
"params": {
"timeout": 10,
"content_type": "json",
"success_codes": [200, 202]
},
"outs": {
"success": 3,
"error": 4
}
},
{
"id": 3,
"type": "event",
"params": {
"channel_id": 10001,
"action_type": 100002,
"event": {
"send_message_id": "$origin.send_message_id"
}
}
},
{
"id": 4,
"type": "event",
"params": {
"channel_id": 10001,
"action_type": 100003,
"event": {
"send_message_id": "$origin.send_message_id",
"message": "$error.code $error.message"
}
}
}
]

Here:

  1. Pipe 1 (Pack) packs data into JSON and passes the event to pipe 2.
  2. Pipe 2 (HTTP Request) sends an HTTP request. On success, the event goes to pipe 3; on error, to pipe 4.
  3. Pipe 3 (event) registers a delivery event.
  4. Pipe 4 (event) registers a non-delivery event with the error code and message.
Last updated on Jul 28, 2026
Previous
Creating a Channel
Next
Message
  • How a pipeline works
    • Flow visualization
    • Working with array data
  • Pipe structure
    • Pipe outputs (OutsObject)
  • Parallel processing
  • Pipeline example
© 2015 - 2026 Altcraft, LLC. All rights reserved.