IPC Named Pipes docs

Tomasz · August 13, 2026, 10:00pm

IPC Server (Named Pipes)

Important: If you are already using existing OLE automation interface, in most cases it doesn't make sense to use named pipes. OLE interface is mature and "just works". Keep using whatever works already for you. There is no reason to change for sake of 'changing' alone. Named pipes interface is experimental and provided mainly for experiments with Python.

Overview

The IPC (Inter-Process Communication) server provides a lightweight JSON-based interface that allows external applications to communicate with and control AmiBroker using Windows Named Pipes.

Typical applications include:

Python scripts
Trading automation
Database management
Integration with external applications
AI assistants and LLMs

Unlike OLE Automation, the IPC server does not rely on COM.

Note: The IPC server is experimental. The protocol and supported commands may be extended in future releases.

Security

Certain functions exposed by IPC server are potentially dangerous and therefore blocked by default. Specifically functions allowing to run arbitrary AFL code (afl_execute, analysis_) present potential for abuse if untrusted code is used.

To enable AFL execution via IPC you need to go to Tools->Preferences, "AI" tab, read the warning message, and confirm that you are aware of the risks and you take responsibility for all those risks and consequences.

Enabling remote AFL code execution via IPC/MCP allows external programs, including AI agents, to execute arbitrary code on this computer.

Depending on the code executed, this may allow them to:

Read, create, modify, or delete files
Access sensitive or private information
Execute system commands and other programs
Modify or destroy application data
Access network resources or external systems
Cause data loss, system instability, or other unintended consequences

An external program or AI agent may also behave unexpectedly, execute incorrect commands, or become compromised.

Only enable this option if you completely trust the programs that will have access to this interface and fully understand the consequences.

Named Pipe

Each running AmiBroker instance creates its own Named Pipe.

The pipe name is:

\\.\pipe\AmiBroker_<PROCESS_ID>

For example:

\\.\pipe\AmiBroker_14320

where 14320 is the Windows process ID (PID) of the AmiBroker instance.

If multiple AmiBroker instances are running simultaneously, each instance exposes its own Named Pipe.

Locating an AmiBroker Instance

Before connecting, an application must determine the PID of the desired AmiBroker process.

Example using Python and psutil:

import psutil

def get_broker_pid():
    process_name = "broker.exe"

    for proc in psutil.process_iter(["pid", "name"]):
        try:
            if proc.info["name"].lower() == process_name.lower():
                return proc.info["pid"]
        except (
            psutil.NoSuchProcess,
            psutil.AccessDenied,
            psutil.ZombieProcess,
        ):
            pass

    return None

pid = get_broker_pid()

if pid:
    pipe_name = fr"\\.\pipe\AmiBroker_{pid}"

Example using C and Windows API:


#include <windows.h>
#include <tlhelp32.h>
#include <stdio.h>
#include <string.h>

DWORD GetFirstAmiBrokerProcess() 
{
    DWORD pid = 0;
   
    const char* processName = "broker.exe";
    
    HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hSnapshot == INVALID_HANDLE_VALUE) {
        return 0;
    }

    PROCESSENTRY32 pe;
    pe.dwSize = sizeof(PROCESSENTRY32);

    if (Process32First(hSnapshot, &pe)) {
        do {
            if (_stricmp(pe.szExeFile, processName) == 0) {
                pid = pe.th32ProcessID;
                break; 
            }
        } while (Process32Next(hSnapshot, &pe));
    }

    CloseHandle(hSnapshot);
    return pid;
}

Applications that support multiple AmiBroker instances may enumerate all matching processes and allow the user to choose the desired instance.

Sending Commands to the named pipe

You send commands just by writing text to the pipe. The commands are formatted as JSON strings.

In Python:


def call_amibroker_import():

    pid = get_broker_pid()

	json_message = """
	{
	    "action": "data_import",
	    "filename": "C:\\Data\\quotes.txt",
	    "import_def": "MyImport.format" 
    }
    """
  
    pipe_name = r'\\.\pipe\AmiBroker_' + str(pid)
 
    response = win32pipe.CallNamedPipe(
            pipe_name,
            json_message,
            10000,
            1000
        )

In C Windows API:


void call_amibroker_import() 
{
    DWORD pid = GetFirstAmiBrokerProcess();

    // Equivalent to the python triple-quoted string (escaping backslashes and quotes)
    const char* json_message = 
        "{\n"
        "    \"action\": \"data_import\",\n"
        "    \"filename\": \"C:\\\\Data\\\\quotes.txt\",\n"
        "    \"import_def\": \"MyImport.format\" \n"
        "}";

    char pipe_name[256];
    // Equivalent to r'\\.\pipe\AmiBroker_' + str(pid)
    snprintf(pipe_name, sizeof(pipe_name), "\\\\.\\pipe\\AmiBroker_%d", pid);

    char response[10000] = {0};
    DWORD bytes_read = 0;

    // Equivalent to win32pipe.CallNamedPipe
    BOOL success = CallNamedPipeA(
        pipe_name,                       // Pipe name
        (LPVOID)json_message,            // Data to write
        (DWORD)strlen(json_message),     // Size of data to write
        response,                        // Buffer to receive response
        sizeof(response),                // Size of response buffer (10000)
        &bytes_read,                     // Bytes actually read
        1000                             // Timeout in ms (1000)
    );

    if (success) 
    {
        printf("Success! Response:\n%.*s\n", (int)bytes_read, response);
    } 
    else 
    {
        printf("CallNamedPipe failed. Error code: %lu\n", GetLastError());
    }
}

Communication Protocol

Communication uses JSON messages.

Each request consists of a single JSON object. Every request must contain an "action" member specifying the command to execute. Additional members depend on the selected action.

Each request produces one JSON response.

The protocol supports three broad categories of operations:

Synchronous operations — the operation completes before the response is returned.
Asynchronous Analysis operations — the request starts an Analysis process and immediately returns an analysis_id.
Analysis control operations — use an existing analysis_id to query, export, or close an Analysis instance.

Successful Responses

Successful commands return:

{
    "success": "<action> completed OK.",
    "result": "<command-specific output>"
}

The result member contains the output of the executed command.

Depending on the command, it may contain:

text produced by an executed AFL formula
an analysis_id for an asynchronously started Analysis
Analysis status information
the current symbol
the list of symbols in the database
a chart export status message
a drawing operation status message
an empty string if the command has no output

Example:

{
    "success": "get_current_symbol completed OK.",
    "result": "MSFT"
}

Error Responses

If a command fails, the response has the following format:

{
    "error": "'<action>' command failed.",
    "error_code": "<numeric error code>",
    "result": "<detailed diagnostic information>"
}

The response members are:

Member	Description
`error`	Short human-readable description of the failure
`error_code`	Numeric error code returned by the operation
`result`	Detailed diagnostic information or command-specific output

Applications should inspect both error_code and result when handling failed requests.

For AFL execution, result may contain compiler or runtime diagnostics.

For Analysis commands, a successful start response means that the Analysis was successfully started; it does not mean that the Analysis has finished.

For chart operations, result contains a human-readable description of the operation's success or failure.

Implementation note: The current implementation formats error_code as a string in the generated JSON response.

Invalid JSON

If the received data is not valid JSON, the server responds with an error containing the parser error code.

The intended response format is:

{
    "error": "invalid JSON (parsing error)",
    "error_code": "<parser_error_code>"
}

Implementation note: The current source code uses = rather than : when constructing the invalid-JSON response:
{ "error" = "invalid JSON (parsing error)", "error_code" = "%d" }
Therefore, the literal response generated by this code is not valid JSON. Clients that need to handle invalid-JSON errors should be aware of this implementation detail.

Supported Commands

The currently implemented commands are:

Action	Description
`data_import`	Import an ASCII data file
`afl_execute`	Execute AFL source code
`analysis_scan`	Start an asynchronous Scan
`analysis_explore`	Start an asynchronous Exploration
`analysis_backtest`	Start an asynchronous portfolio backtest
`analysis_backtest_individual`	Start an asynchronous individual backtest
`analysis_optimize`	Start an asynchronous optimization
`analysis_optimize_individual`	Start an asynchronous individual optimization
`analysis_walkforward`	Start an asynchronous walk-forward analysis
`analysis_export`	Export results from an Analysis
`analysis_export_walkforward`	Export walk-forward results
`analysis_get_status`	Get the status of an Analysis
`analysis_close`	Close an Analysis instance
`chart_export_image`	Export the active chart as an image
`chart_draw_line`	Add a trend line to the active chart
`chart_delete_all_lines`	Delete all drawings from the active chart
`get_symbol_list`	Get all symbols in the database
`get_current_symbol`	Get the currently selected symbol
`set_current_symbol`	Change the currently selected symbol

Data Import

data_import

Imports an ASCII file using an existing Import Definition.

Request

{
    "action": "data_import",
    "filename": "C:\\Data\\quotes.txt",
    "import_def": "MyImport.format"
}

Parameters

Parameter	Description
`filename`	ASCII file to import
`import_def`	Name of the Import Definition to use

The server calls AmiBroker's ASCII import functionality using the specified file and Import Definition.

Successful Response

The import operation does not explicitly populate result, so a successful response normally contains an empty result:

{
    "success": "data_import completed OK.",
    "result": ""
}

AFL Execution

afl_execute

Executes an AFL formula.

Request

{
    "action": "afl_execute",
    "formula": "printf(\"Current symbol: %s\\n\", Name());"
}

Parameters

Parameter	Description
`formula`	AFL source code to execute

Successful Response

On success, the result field contains the text output generated by the AFL formula.

This is the output produced by AFL text-output functions such as printf().

Example:

Request:

{
    "action": "afl_execute",
    "formula": "printf(\"Current symbol: %s\\n\", Name());"
}

Response:

{
    "success": "afl_execute completed OK.",
    "result": "Current symbol: MSFT\n"
}

If the formula produces no text output, result is an empty string.

Error Response

If compilation or execution fails:

{
    "error": "'afl_execute' command failed.",
    "error_code": "1",
    "result": "Error 30. Syntax error.\nLine 3, Column 15."
}

The result member contains detailed compiler or runtime diagnostics whenever available.

Analysis

The Analysis commands are asynchronous.

Starting an Analysis does not wait for the Scan, Exploration, Backtest, Optimization, or Walk-forward operation to finish.

Instead, the start command:

Starts the Analysis.
Returns an analysis_id.
Allows the client to continue doing other work.
Uses analysis_get_status to determine whether the Analysis is still running (status "Busy") or has completed (status "Idle")

The analysis_id is the identifier of the Analysis instance and must be retained by the client.

Analysis Workflow

The normal workflow is:

Start Analysis
      │
      ▼
 receive analysis_id
      │
      ▼
analysis_get_status
      │
      ├── still running ("Busy") ──► wait ──► analysis_get_status
      │
      └── completed
              │
              ▼
        export results
              │
              ▼
        analysis_close

The Analysis-start commands are:

analysis_scan
analysis_explore
analysis_backtest
analysis_backtest_individual
analysis_optimize
analysis_optimize_individual
analysis_walkforward

A successful response from one of these commands means the Analysis was started successfully, not that the Analysis itself has completed.

analysis_scan

Starts an Analysis Scan asynchronously.

Request

{
    "action": "analysis_scan",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

The result contains the identifier of the newly started Analysis:

{
    "success": "analysis_scan completed OK.",
    "result": "<analysis_id>"
}

For example:

{
    "success": "analysis_scan completed OK.",
    "result": "12345"
}

The client should retain 12345 and use it with analysis_get_status.

analysis_explore

Starts an Analysis Exploration asynchronously.

Request

{
    "action": "analysis_explore",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

{
    "success": "analysis_explore completed OK.",
    "result": "<analysis_id>"
}

The returned identifier represents the running Analysis instance.

analysis_backtest

Starts a portfolio backtest asynchronously.

Request

{
    "action": "analysis_backtest",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

{
    "success": "analysis_backtest completed OK.",
    "result": "<analysis_id>"
}

The backtest continues running after the IPC request returns.

analysis_backtest_individual

Starts an individual backtest asynchronously.

Request

{
    "action": "analysis_backtest_individual",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

{
    "success": "analysis_backtest_individual completed OK.",
    "result": "<analysis_id>"
}

analysis_optimize

Starts an Analysis optimization asynchronously.

Request

{
    "action": "analysis_optimize",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

{
    "success": "analysis_optimize completed OK.",
    "result": "<analysis_id>"
}

Optimization may take substantially longer than a Scan or Exploration. Clients should use analysis_get_status rather than assuming the optimization has completed when the start request returns.

analysis_optimize_individual

Starts an individual optimization asynchronously.

Request

{
    "action": "analysis_optimize_individual",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

{
    "success": "analysis_optimize_individual completed OK.",
    "result": "<analysis_id>"
}

analysis_walkforward

Starts a walk-forward Analysis asynchronously.

Request

{
    "action": "analysis_walkforward",
    "filename": "C:\\Analysis\\MyAnalysis.apx"
}

Parameters

Parameter	Description
`filename`	Analysis project/file to execute

Successful Response

{
    "success": "analysis_walkforward completed OK.",
    "result": "<analysis_id>"
}

The walk-forward operation continues asynchronously. Use analysis_get_status to determine when it has completed.

Analysis Status

analysis_get_status

Returns the current status of an Analysis instance.

Request

{
    "action": "analysis_get_status",
    "analysis_id": "12345"
}

Parameters

Parameter	Description
`analysis_id`	Identifier returned when the Analysis was started

The command can be called repeatedly every second while an Analysis is running (i.e. while it returns "Busy"). If it reports "Idle" it means that it has completed.

Successful Response

{
    "success": "analysis_get_status completed OK.",
    "result": "<status information>"
}

The exact contents of result are returned by the Analysis subsystem.

Clients should use this command to determine whether the Analysis is still running or has completed.

Polling

A client should poll at a reasonable interval rather than continuously calling the status command in a tight loop.

Conceptually:

analysis_id = start_analysis()

while True:
    status = get_analysis_status(analysis_id)

    if status != "Busy":
        break

    time.sleep(1)

The exact completion value or status representation should be determined from the result returned by AmiBroker.

Analysis Export

Analysis export operations work with results produced by an Analysis instance.

They should normally be performed only after the associated Analysis has completed.

The export commands are:

analysis_export
analysis_export_walkforward

The recommended sequence is:

start Analysis
      │
      ▼
analysis_id
      │
      ▼
poll analysis_get_status every second (while it is "Busy")
      │
      ▼
Analysis completed
      │
      └──► analysis_export

Attempting to export before the Analysis has completed may fail because the required results are not yet available.

analysis_export

Exports Analysis results.

Request

{
    "action": "analysis_export",
    "filename": "C:\\Analysis\\MyAnalysis.apx",
    "analysis_id": "12345"
}

Parameters

Parameter	Description
`filename`	Analysis project/file
`analysis_id`	Identifier of the Analysis instance

The analysis_id is the identifier returned by an Analysis-start command.

The export should be performed after analysis_get_status indicates that the Analysis has completed.

analysis_export_walkforward

Exports walk-forward Analysis results.

Request

{
    "action": "analysis_export_walkforward",
    "analysis_id": "12345"
}

Parameters

Parameter	Description
`analysis_id`	Identifier of the Analysis instance

Unlike analysis_export, this command does not require a filename.

It should be called after the corresponding walk-forward Analysis has completed.

Analysis Close

analysis_close

Closes an Analysis instance.

Request

{
    "action": "analysis_close",
    "analysis_id": "12345"
}

Parameters

Parameter	Description
`analysis_id`	Identifier of the Analysis instance

The client should retain the analysis_id until all required operations, including status checking and result export, have completed.

When the Analysis instance is no longer required, the client can call analysis_close.

Complete Analysis Example

The following illustrates the recommended lifecycle.

1. Start a backtest

Request:

{
    "action": "analysis_backtest",
    "filename": "C:\\Analysis\\MyBacktest.apx"
}

Response:

{
    "success": "analysis_backtest completed OK.",
    "result": "12345"
}

The client stores:

analysis_id = 12345

The backtest is now running asynchronously.

2. Check status in a loop

Request:

{
    "action": "analysis_get_status",
    "analysis_id": "12345"
}

The client repeats the request every second until the returned status indicates that the Analysis has completed (i.e. reports "Idle", not "Busy")

3. Export results

After completion:

{
    "action": "analysis_export",
    "filename": "C:\\Analysis\\MyBacktest.apx",
    "analysis_id": "12345"
}

For a walk-forward Analysis:

{
    "action": "analysis_export_walkforward",
    "analysis_id": "12345"
}

4. Close the Analysis

When the Analysis is no longer required:

{
    "action": "analysis_close",
    "analysis_id": "12345"
}

Analysis Command Summary

Action	Asynchronous	`analysis_id`	Description
`analysis_scan`	Yes	Returns	Start Scan
`analysis_explore`	Yes	Returns	Start Exploration
`analysis_backtest`	Yes	Returns	Start portfolio backtest
`analysis_backtest_individual`	Yes	Returns	Start individual backtest
`analysis_optimize`	Yes	Returns	Start optimization
`analysis_optimize_individual`	Yes	Returns	Start individual optimization
`analysis_walkforward`	Yes	Returns	Start walk-forward analysis
`analysis_get_status`	No	Uses	Check Analysis status
`analysis_export`	No	Uses	Export completed Analysis results
`analysis_export_walkforward`	No	Uses	Export completed walk-forward results
`analysis_close`	No	Uses	Close Analysis instance

Important: A successful response from an Analysis-start command means that the Analysis was successfully started, not that it has completed. Always retain the returned analysis_id and use analysis_get_status to determine completion (wait as long as it is in "Busy" state) before attempting to export results.

Chart Commands

Chart commands operate on the currently active AmiBroker chart/view.

They use the active child frame and its active chart view. Therefore, applications should ensure that the intended chart is active before issuing a chart command.

chart_export_image

Exports the currently active chart to an image file.

Request

{
    "action": "chart_export_image",
    "filename": "C:\\Exports\\chart.png"
}

Parameters

Parameter	Required	Description
`filename`	Yes	Output image filename
`width`	No	Requested image width in pixels
`height`	No	Requested image height in pixels

Example with explicit dimensions:

{
    "action": "chart_export_image",
    "filename": "C:\\Exports\\chart.png",
    "width": "1600",
    "height": "900"
}

If width or height is omitted or evaluates to zero, the implementation passes -1, causing AmiBroker to use its default dimension.

Successful Response

{
    "success": "chart_export_image completed OK.",
    "result": "Exported OK"
}

Failed Response

{
    "error": "'chart_export_image' command failed.",
    "error_code": "1",
    "result": "Export failed"
}

chart_draw_line

Adds a trend line to the currently active chart.

Request

{
    "action": "chart_draw_line",
    "start_date": "20260101",
    "start_value": "100.0",
    "end_date": "20260801",
    "end_value": "150.0",
    "color": "#FF0000"
}

Parameters

Parameter	Description
`start_date`	Start date of the trend line
`start_value`	Value at the start point
`end_date`	End date of the trend line
`end_value`	Value at the end point
`color`	Hexadecimal RGB color, normally specified as `#RRGGBB`

The dates are converted using AmiBroker's internal date conversion.

The values are converted to floating-point numbers.

The drawing is associated with the currently active chart.

Color

The implementation expects the color value to contain a leading # and parses the hexadecimal portion after it.

For example:

#FF0000

represents red.

Successful Response

{
    "success": "chart_draw_line completed OK.",
    "result": "Trend line added"
}

Failed Response

{
    "error": "'chart_draw_line' command failed.",
    "error_code": "1",
    "result": "Failed. Can't add a trend line"
}

chart_delete_all_lines

Deletes all drawings from the currently active chart.

Despite its name, the implementation does not specifically filter for trend lines. It removes the drawings associated with the current chart.

Request

{
    "action": "chart_delete_all_lines"
}

Successful Response

{
    "success": "chart_delete_all_lines completed OK.",
    "result": "Deleted all drawings from current chart"
}

Failed Response

{
    "error": "'chart_delete_all_lines' command failed.",
    "error_code": "1",
    "result": "Failed. Can't delete lines"
}

Symbol Commands

get_symbol_list

Returns all symbols in the current database.

Request

{
    "action": "get_symbol_list"
}

Successful Response

{
    "success": "get_symbol_list completed OK.",
    "result": "AAPL\nMSFT\nNVDA\n..."
}

The symbols are returned as a newline-separated list.

get_current_symbol

Returns the currently selected symbol.

Request

{
    "action": "get_current_symbol"
}

Successful Response

{
    "success": "get_current_symbol completed OK.",
    "result": "AAPL"
}

set_current_symbol

Changes the currently selected symbol.

Request

{
    "action": "set_current_symbol",
    "symbol": "MSFT"
}

Parameters

Parameter	Description
`symbol`	Symbol to select

Existing Symbol

If the symbol exists:

{
    "success": "set_current_symbol completed OK.",
    "result": "Symbol changed OK"
}

Symbol Does Not Exist

If the specified symbol does not exist:

{
    "success": "set_current_symbol completed OK.",
    "result": "Symbol does not exist in the database"
}

The request is considered successfully processed even when the requested symbol does not exist.

Applications that need to determine whether the active symbol actually changed should therefore inspect the result member.

Active Chart Considerations

The chart commands operate on the active chart at the time the request is processed.

In particular:

chart_export_image exports the active chart.
chart_draw_line adds the drawing to the active chart.
chart_delete_all_lines removes drawings from the active chart.
Chart operations require a valid active child frame/view.
Changing the selected symbol and changing the active chart are separate concepts.
Applications should ensure that the intended chart is active before performing chart operations.

Character Escaping

Returned strings are escaped before being inserted into the JSON response.

Special characters are escaped using JSON-compatible escaping.

In addition, percent characters (%) are replaced with:

\u0025

This is done before constructing the final response string.

Clients should JSON-decode the response normally. The JSON Unicode escape \u0025 represents the % character.

Typical Workflow

A basic IPC workflow is:

Locate the desired AmiBroker process.
Construct the Named Pipe name:
```
\\.\pipe\AmiBroker_<PID>
```
Connect to the Named Pipe.
Send a JSON request.
Read the JSON response.
Inspect success or error, together with error_code and result.
Send additional requests or close the connection.

For synchronous commands such as AFL execution, symbol management, data import, and chart operations, the response represents the result of the requested operation.

For Analysis operations:

Start the Analysis.
Store the returned analysis_id.
Poll analysis_get_status.
Wait until the Analysis is complete.
Export results if required.
Close the Analysis instance when finished.

Example Session

Get Current Symbol

Request:

{
    "action": "get_current_symbol"
}

Response:

{
    "success": "get_current_symbol completed OK.",
    "result": "AAPL"
}

Execute AFL

Request:

{
    "action": "afl_execute",
    "formula": "printf(\"Hello from AFL\\n\");"
}

Response:

{
    "success": "afl_execute completed OK.",
    "result": "Hello from AFL\n"
}

Import Data

Request:

{
    "action": "data_import",
    "filename": "C:\\Data\\quotes.txt",
    "import_def": "MyImport.format"
}

Start a Backtest

Request:

{
    "action": "analysis_backtest",
    "filename": "C:\\Analysis\\MyBacktest.apx"
}

Response:

{
    "success": "analysis_backtest completed OK.",
    "result": "12345"
}

The value 12345 is the analysis_id.

The backtest is still running at this point.

Check Analysis Status

Request:

{
    "action": "analysis_get_status",
    "analysis_id": "12345"
}

Response:

When Analysis is busy working:

{
    "success": "analysis_get_status completed OK.",
    "result": "Busy"
}

When Analysis has completed:

{
    "success": "analysis_get_status completed OK.",
    "result": "Idle"
}

The value returned will be either "Busy" or "Idle", depending on running status of Analysis window

Repeat this request every second as long as the Analysis reports that it is busy.

Export Completed Backtest

After completion:

{
    "action": "analysis_export",
    "filename": "C:\\Analysis\\MyBacktest.apx",
    "analysis_id": "12345"
}

Close Analysis

When the Analysis is no longer needed:

{
    "action": "analysis_close",
    "analysis_id": "12345"
}

Export a Chart

Request:

{
    "action": "chart_export_image",
    "filename": "C:\\Exports\\MSFT.png",
    "width": "1600",
    "height": "900"
}

Response:

{
    "success": "chart_export_image completed OK.",
    "result": "Exported OK"
}

Draw a Trend Line

Request:

{
    "action": "chart_draw_line",
    "start_date": "20260101",
    "start_value": "100",
    "end_date": "20260801",
    "end_value": "150",
    "color": "#FF0000"
}

Response:

{
    "success": "chart_draw_line completed OK.",
    "result": "Trend line added"
}

Delete Chart Drawings

Request:

{
    "action": "chart_delete_all_lines"
}

Response:

{
    "success": "chart_delete_all_lines completed OK.",
    "result": "Deleted all drawings from current chart"
}

AFL Error

Request:

{
    "action": "afl_execute",
    "formula": "Plot(Close"
}

Response:

{
    "error": "'afl_execute' command failed.",
    "error_code": "29",
    "result": "Syntax error.\nLine 1, Column 11."
}

Supported Programming Languages

The IPC server uses a simple JSON protocol transported over Windows Named Pipes. Any programming language capable of opening a Windows Named Pipe and reading/writing text can communicate with AmiBroker.

davem · August 17, 2026, 11:32am

This looks so good, Tomasz! Thanks for your work on this excellent software.

One question about this interface: I often run two instances of Amibroker, each connected to a different database.

Is there a way to tell which instance is connected to which database using this interface?

When using the current COM interface, I make sure only one instance of Amibroker is running, but with this named pipes interface, it opens up new possibilities.

Tomasz · August 17, 2026, 11:38am

Quote:

Named Pipe

Each running AmiBroker instance creates its own Named Pipe.

The pipe name is:
\\.\pipe\AmiBroker_<PROCESS_ID>
For example:
\\.\pipe\AmiBroker_14320
where 14320 is the Windows process ID (PID) of the AmiBroker instance.

If multiple AmiBroker instances are running simultaneously, each instance exposes its own Named Pipe.

davem · August 17, 2026, 2:17pm

What do you suggest for getting the database in use by the Amibroker instance from the named pipe?

Tomasz · August 17, 2026, 5:35pm

This is only available from OLE as of now.