API Fundamentals

The PQFORCE API is designed according to widely adopted REST (Representational State Transfer) principles. These principles ensure a clear, predictable, and scalable interface that can be consumed by a broad range of clients and integration scenarios. Understanding these fundamentals is essential before working with individual endpoints or data models.

REST Principles

The PQFORCE API follows a stateless communication model. Each HTTP request is treated as an independent operation and must contain all information required to process it. No client-specific session state is stored on the server between requests. This approach simplifies horizontal scaling, improves reliability, and allows integrations to be implemented in a robust and repeatable manner.

All request and response payloads are exchanged in JSON format. JSON provides a lightweight, human-readable representation of structured data and is well supported by modern programming languages and integration frameworks. Clients should assume that both request bodies and response payloads are encoded as UTF-8 JSON and that standard HTTP status codes are used to signal the outcome of an operation.

The API is resource-oriented. Core business entities such as projects or portfolios are exposed as resources that can be accessed via clearly structured URLs. Standard HTTP methods are used to interact with these resources in a consistent way: for example, GET requests to retrieve data, POST requests to create new resources, PUT requests to update existing data, and DELETE requests to remove resources. This consistent use of HTTP semantics makes the API intuitive to use and easy to integrate with existing REST tooling.

Base URL and Versioning

All PQFORCE API endpoints are exposed under a common base URL (per API version). The base URL for the most recent version is /API/V2/.

Versioning the API in the URL allows the interface to evolve over time without breaking existing integrations. New versions may introduce additional functionality, structural changes, or behavioral improvements, while older versions remain available for a defined period to ensure backward compatibility. Clients are expected to explicitly target a specific API version and should not assume that newer versions are fully compatible with older ones.