Skip to main content

Overview

KiCad’s IPC API provides a modern, language-agnostic interface for external applications to interact with KiCad. Built on Protocol Buffers and NNG (Nanomsg Next Generation), it enables real-time communication with running KiCad instances.

Architecture

The API uses a client-server model:
  • Server: KiCad application (KICAD_API_SERVER)
  • Client: External tools, scripts, or applications
  • Transport: IPC sockets (named pipes on Windows, Unix domain sockets on Linux/macOS)
  • Protocol: Protocol Buffers (protobuf) over NNG request-reply pattern

Core Components

Protocol Definition

Envelope Structure

All messages are wrapped in an envelope (api/proto/common/envelope.proto):

Board Commands

Defined in api/proto/board/board_commands.proto:

Get Board Stackup

Example Usage:

Get/Set Layers

Net Management

Zone Operations

Board Origins

DRC Integration

Editor Appearance

Interactive Commands

Visibility and Selection

Implementing a Client

Python Example

C++ Example

Advanced Features

Padstack Analysis

Pad Shape Computation

Error Handling

Best Practices

  1. Always set client_name: Helps with debugging and logging
  2. Handle AS_BUSY: Some operations are blocking (zone fills, etc.)
  3. Validate token: Token changes when KiCad restarts
  4. Use timeouts: Set socket timeouts to avoid hanging
  5. Batch operations: Minimize round-trips for better performance
  6. Check status codes: Always verify AS_OK before unpacking response

Security Considerations

  • Token authentication: Prevents unauthorized access
  • Local sockets only: IPC sockets are not network-accessible
  • File permissions: Socket and token files have restricted permissions
  • No remote access: API is designed for local tool integration only

See Also