Sign in Subscribe

Mastering the Polarion API — A Developer’s Guide to Extensions and Integrations

Phillip Bösger

• 3 min read
Mastering the Polarion API — A Developer’s Guide to Extensions and Integrations

A practical overview of what’s possible with Polarion’s API and how to extend its capabilities effectively.

Why the API landscape matters

If you understand Polarion’s API surface, you can extend the system fast and safely: fewer reworks, cleaner upgrades, and solutions that map directly to your use cases. This post gives a current overview of the available APIs and where extensions fit.

The Polarion API — 2025 Overview

Polarion API's - Overview
Use the REST API for external integrations and most data operations. OpenAPI (Old API) and the Rendering API are relevant for in-product contexts. The WebService API is effectively retired.

REST API

  • Strengths: JSON over HTTP, full CRUD for core objects (work items, links, comments, attachments, fields). Automatable and CI/CD-friendly.
  • Ideal for: External integrations and system-to-system data exchange; can also be called from reports/widgets.
  • Notes: Auth via Bearer token (PAT generated in the Polarion UI).

OpenAPI (Old API)

  • Strengths: In-process access to Polarion’s domain services (e.g., IDataService, ITrackerService, IRepoService, IWorkItem). Tight coupling to workflow and templating.
  • Ideal for: Workflow functions & conditions, Velocity macros, and the initial build/resolve/render cycle of widgets before client-side JS runs.

Rendering API

  • Strengths: Read-only, performant access tailored for rendering (ReadOnlyTransaction, render classes). Easiest way to display data in pages/reports.
  • Ideal for: UI/reporting contexts where you format and output Polarion data without mutations.

WebService API

  • Reality: Not used going forward. Plan migrations to REST.

Extending Polarion — What you can build

Extension Overview
  • Save Hooks (via OOTB Scripting Engine, JavaScript) — Trigger logic on save to validate, enrich, or normalize data without server restarts.
  • Macro & Wiki Script (Velocity + CSS/JS) — Lightweight UI enrichments. Keep macros thin; call REST, Polarion APIs, or small utilities for logic.
  • Widget & Form Extensions (Velocity or Java) — Custom UI behavior and validations. Separate presentation from business logic.
  • Jobs (Java, JavaScript) — Scheduled/background work. Use JS for quick, iterative tasks; use Java for heavier, library-rich workloads.
  • Workflow Condition / Function (Java, JavaScript, Groovy, or Velocity) — Enforce business rules on transitions and actions.
  • Velocity Context Extension (Java) — Expose focused server-side utilities into Velocity.
  • Custom Enumeration or Notification Handler (Java) — Domain types and event-driven reactions (state changes, links, comments).
  • Dynamic Permissions (Java) — Compute permissions at runtime based on business rules.
  • Connectors (Java/JS or via REST; legacy WebService) — Integrate and synchronize with other systems or export data from Polarion. WebService is legacy—prefer REST.
  • HTML Injection (HTML, JS) — Inline augmentations for content rendering (use sparingly and sanitize inputs).

About Polarion-like Custom Connectors

Think of an “Azure DevOps” or “Jira”-style connector inside Polarion. There is no official Polarion API to develop such connectors. Given current compliance pressures (e.g., the EU Cyber Resilience Act), creating or distributing custom connectors of this kind is not recommended. If you still need one—or want to understand the options to build it—reach out to me.

What’s next

This post focuses on what exists and where it fits. If you want hands-on scenarios—end-to-end examples for synchronization, event-driven policies, and reporting—leave a comment. I’ll cover practical blueprints (with tests and deployment patterns) in a follow-up.