BLOG

Introducing the ProBG Time Tracking REST API v1

06.10.2026

We are introducing the ProBG Time Tracking REST API v1 — a secure, read-only API designed to make time-tracking data available to external systems, reporting tools, and custom integrations.

The API provides structured access to clients, projects, and time entries while preserving the same account isolation and access-control principles used throughout ProBG Time Tracking.

Whether you need to synchronize tracked time with an ERP system, build a custom management dashboard, export project data to a BI platform, or connect ProBG Time Tracking to an internal business application, API v1 provides a stable foundation for these integrations.

Public API Documentation

The complete API documentation is publicly available and does not require authentication.

API Documentation: https://tracker.probg.com/api/docs

The documentation is available in both English and Bulgarian:

For developers who prefer working directly with API specifications or development tools, we also provide:

The OpenAPI specification can be used with tools such as Swagger, Redoc, Insomnia, Postman, and SDK-generation tools.

What Can You Access Through API v1?

The first version of the API focuses on the core reporting and synchronization use cases. It currently provides read-only access to three primary resources: Clients, Projects, and Time Entries.

Clients

Integrations can retrieve the clients associated with the authenticated account using: 

GET /clients
GET /clients/{id}

The client list supports filtering by status, search terms, and modification date. Returned information can include the client's name, company, contact details, number of projects, tracked time, archive status, and creation or modification timestamps.

Projects

Project information is available through: 

GET /projects
GET /projects/{id}

Projects can be filtered by client, status, search query, and modification date.

The API exposes useful project information such as:

  • client relationship;
  • project status;
  • billing model;
  • billing currency;
  • hourly rate;
  • fixed-fee amount;
  • retainer amount;
  • estimated time;
  • total tracked time;
  • project start and end dates.

Sensitive internal labor-cost information is deliberately excluded from API responses.

Time Entries

Tracked time is available through: 

GET /time-entries
GET /time-entries/{id}

The endpoint provides filtering options including:

  • client;
  • project;
  • task;
  • user;
  • date range;
  • billable status;
  • billed status;
  • text search;
  • modification date.

This makes it possible to build integrations such as monthly project exports, external reports, accounting workflows, or synchronization with another business system.

For example, retrieving all tracked time for a project during October can be done with: 

GET /time-entries?project_id=12&from=2026-10-01&to=2026-10-31&per_page=100

Time durations are returned in seconds, while dates and timestamps follow standardized formats suitable for automated processing.

Secure Bearer Token Authentication

API v1 uses Bearer token authentication. Each external integration should use its own dedicated API token.

A request uses the following HTTP headers:

Authorization: Bearer ptt_...
Accept: application/json

API tokens belong to a specific account. The account cannot be selected by passing an external account_id parameter.

Instead, account context is determined exclusively by the authentication token. This prevents an integration from attempting to switch between accounts by manipulating request parameters.

For additional security, ProBG Time Tracking stores only a SHA-256 hash of the API token. The full token is displayed only when it is created and cannot later be recovered from the system.

Fine-Grained API Scopes

API tokens support granular access permissions through scopes.

  • clients:read — access to client lists and client details;
  • projects:read — access to project lists and project details;
  • time:read — access to time-entry lists and time-entry details.

An integration therefore does not need access to every API resource.

For example, an external reporting application that only processes tracked time can receive the time:read scope without being granted unnecessary access to other API resources.

This follows the principle of least privilege and reduces the potential impact of a compromised integration token.

Token Expiration and Revocation

When creating an API token, an Account Administrator can configure its lifetime.

Available expiration options include:

  • 30 days;
  • 90 days;
  • 365 days;
  • no automatic expiration.

Tokens can also be revoked manually at any time.

API access stops immediately when:

  • the token is revoked;
  • the token expires;
  • the account is suspended;
  • the current subscription no longer includes API access.

For long-running integrations, we recommend using a separate token for every application and periodically rotating long-lived credentials.

Account Isolation by Design

Tenant isolation is an important part of the API architecture.

Every API request operates only inside the account associated with the supplied token. Resources belonging to another account are never returned.

If an integration attempts to access an ID belonging to another account, the API responds with 404 Not Found instead of revealing whether that resource exists.

This behavior helps prevent information disclosure across accounts.

Pagination and Synchronization

All list endpoints use pagination.

The default page size is 25 records, while integrations can request up to 100 records per page.

API responses include pagination metadata together with navigation links, allowing an integration to continue requesting pages until links.next becomes null.

For ongoing synchronization, API v1 also supports the updated_since filter. 

GET /clients?updated_since=2026-10-06T08:00:00Z
GET /projects?updated_since=2026-10-06T08:00:00Z
GET /time-entries?updated_since=2026-10-06T08:00:00Z

This enables incremental synchronization instead of repeatedly downloading the account's complete dataset.

The feature is particularly useful for CRM, ERP, analytics, business intelligence, and data-warehouse integrations.

Predictable Error Handling

The API uses standard HTTP status codes and structured JSON error responses.

  • 401 — missing, invalid, expired, or revoked token;
  • 403 — insufficient scope, unavailable account, or API access not included in the current subscription;
  • 404 — resource not found or not available to the current account;
  • 422 — invalid request parameters;
  • 429 — rate limit exceeded.

Structured errors make failures easier for external applications to detect and handle programmatically.

API Rate Limits

To protect the platform and provide predictable service for all accounts, API access is rate-limited.

Each API token currently supports up to:

  • 120 requests per minute;
  • 3,000 requests per hour.

Additional IP-level safety limits of 600 requests per minute and 10,000 requests per hour are also applied.

Integrations receiving a 429 Too Many Requests response should reduce request frequency and use appropriate retry logic with exponential backoff.

Ready-to-Use Postman Collection

To make development and testing easier, we provide an official Postman Collection v2.1.

Download the ProBG Time Tracking API Postman Collection

After importing the collection into Postman, developers only need to configure several collection variables:

  • base_url
  • token
  • client_id
  • project_id
  • time_entry_id

The default API base URL is:

https://tracker.probg.com/api/v1

Bearer authentication is configured at collection level through the token variable, so the same token is automatically used for all included requests.

The collection contains ready-to-use requests grouped into:

  • Clients;
  • Projects;
  • Time Entries.

Optional query parameters are included in a disabled state and can be enabled when needed for a particular integration.

Basic collection tests also verify JSON responses and help detect unexpected server-side errors.

OpenAPI 3.1 Support

For teams that prefer specification-driven development, the complete REST API contract is available as an OpenAPI 3.1 YAML specification.

Download the OpenAPI 3.1 specification

The specification can be imported into Postman, Insomnia, Swagger UI, Swagger Editor, Redoc, and compatible SDK-generation tools.

This provides developers with a machine-readable API contract alongside the human-readable documentation.

API Availability by Subscription Plan

API access is controlled through the api entitlement of the account's subscription.

By default, API access is enabled for:

  • Agency;
  • Enterprise.

A Platform Administrator can also configure API availability at plan level or through an individual account override.

This allows API functionality and subscription capabilities to evolve independently while keeping access centrally controlled.

Designed for Real Integration Workflows

API v1 is intentionally focused on reliable data access rather than attempting to expose every feature of ProBG Time Tracking immediately.

CRM and ERP Synchronization

Synchronize clients, projects, and tracked working time with existing CRM, ERP, or internal business systems.

Business Intelligence and Analytics

Import project and time-tracking data into BI platforms, reporting tools, or custom management dashboards.

Accounting and Billing Workflows

Retrieve billable and billed time entries for downstream accounting, invoicing, and financial processing.

External Reporting

Build custom client, project, management, or operational reports outside ProBG Time Tracking.

Data Warehouse Synchronization

Use the updated_since filter to incrementally synchronize changes into external databases and data platforms.

What Is Not Included in API v1?

The first API release is deliberately read-only.

The following capabilities are not currently part of the v1 contract:

  • create, update, or delete operations;
  • dedicated Tasks endpoints;
  • Reports endpoints;
  • Invoices endpoints;
  • Webhooks;
  • OAuth or client-credentials authentication;
  • bulk export endpoints.

These capabilities can be introduced in future API versions after defining the appropriate contracts, permission model, and security requirements.

Keeping API v1 focused also gives integrations built today a smaller and more stable interface to depend on.

Versioned for Long-Term Compatibility

The API base URL includes its version:

https://tracker.probg.com/api/v1

Breaking authentication changes or incompatible response-contract changes will require a new namespace such as /api/v2.

Within v1, the API may introduce additional optional fields, optional filters, or new endpoints without breaking existing integrations.

Integrations should therefore avoid assuming that API response objects will always contain only the fields available today.

This versioning strategy provides developers with a predictable API contract while allowing ProBG Time Tracking to continue evolving.

Security Recommendations

When integrating with the API, we recommend following several basic security practices:

  • create a separate API token for every integration;
  • grant only the scopes that the integration actually needs;
  • never commit API tokens to Git repositories;
  • never expose tokens in frontend JavaScript;
  • avoid exposing credentials in screenshots or public logs;
  • store tokens in environment variables or a secure secret manager;
  • always communicate with the API over HTTPS;
  • revoke compromised or unused tokens immediately;
  • periodically rotate long-lived tokens;
  • use exponential backoff when handling rate-limit responses.

Start Building with the ProBG Time Tracking API

The ProBG Time Tracking REST API provides the first dedicated integration layer between the platform and external business systems.

Developers can start with the public API documentation, import the Postman collection for immediate testing, or use the OpenAPI 3.1 specification as the foundation for their preferred development workflow.

API Documentation:
https://tracker.probg.com/api/docs

Postman Collection:
https://tracker.probg.com/api/docs/postman.json

OpenAPI 3.1 Specification:
https://tracker.probg.com/api/docs/openapi.yaml

The current API establishes a secure, account-isolated, and extensible foundation for future integrations while providing immediate access to the data most commonly required by external systems: clients, projects, and tracked time.

← Back to blog