--- title: Pivotal Tracker API Integration on Truto slug: pivotaltracker category: Ticketing canonical: "https://truto.one/integrations/detail/pivotaltracker/" --- # Pivotal Tracker API Integration on Truto **Category:** Ticketing **Status:** Generally available ## Unified APIs ### Unified User Directory API - **Me** — - **Roles** — The Role object represents a role of a User. - **Users** — The User object represents a User. - **Workspaces** — Workspaces represent concepts like teams, workspaces, projects in apps that support them ### Unified Ticketing API - **Accounts** — Accounts represent the companies or organizations that you are in contact with. Accounts have one or more Contacts associated with them. - **Attachments** — Attachments are the files associated with a ticket or a comment. - **Collections** — Tickets and contacts can be grouped into Collections. Collection resource usually maps to the various grouping systems used in the underlying product. Some examples are lists, projects, epics, etc. You can differentiate between these grouping systems using the type attribute of a Collection. - **Comments** — Comments represent the communication happening on a Ticket, both between a User and a Contact and the internal things like notes, private comments, etc. A Ticket can have one or more Comments. - **Tags** — Tags represent a common classification approach used in various ticketing systems. A Ticket may have one or more Tags associated with them. - **Tasks** — Task represent a smaller subdivision of a Ticket, which could be the list of things to do in a Ticket. - **Ticket Priorities** — Ticket Priorities represent the intended order in which the Tickets should be worked on. Some products provide customizing the Ticket Priorities. - **Ticket Types** — Ticket Types represent the classification system used by the underlying products for Tickets. Some examples are bugs, feature, incident, etc. - **Tickets** — Core resource which represents some work that needs to be carried out. Tickets are usually mapped to issues, tasks, work items, etc. depending on the underlying product. - **Users** — Users represent the people using the underlying ticketing system. They are usually called agents, team members, admins, etc. - **Workspaces** — Workspaces represent the top-level subdivision in a ticketing system. They usually have their own set of settings, tickets, statuses, priorities and users. Some of the usual terminologies used by the products for the top-level subdivision are projects, bases, spaces, workspace, etc. A Workspace could belong to an Organization. ## How it works 1. **Link your customer's Pivotal Tracker account.** Use Truto's frontend SDK; we handle every OAuth and API key flow so you don't need to create the OAuth app. 2. **Authentication is automatic.** Truto refreshes tokens, stores credentials securely, and injects them into every API request. 3. **Call Truto's API to reach Pivotal Tracker.** The Proxy API is a 1-to-1 mapping of the Pivotal Tracker API. 4. **Get a unified response format.** Every response uses a single shape, with cursor-based pagination and data in the `result` field. ## Use cases - **One-click migration from Pivotal Tracker to your platform** — Project management tools can offer displaced Pivotal Tracker users a seamless migration path by pulling their entire historical backlog — stories, epics, labels, attachments, and comments — through Truto's Unified Ticketing API, reducing onboarding friction and accelerating customer acquisition. - **Preserve multi-year engineering velocity metrics across tool transitions** — Engineering analytics platforms can ingest historical tickets, story point estimates, and iteration data from Pivotal Tracker and merge it with data from a customer's new ticketing tool, ensuring continuous long-term performance reporting without a data gap during migration. - **Compliance-grade archival of legacy development records** — Backup and compliance SaaS products can pull a complete, read-only snapshot of all users, tickets, comments, attachments, and workspace structures from Pivotal Tracker before API access is fully decommissioned, helping enterprise customers satisfy SOC 2 and ISO audit requirements for historical software releases. - **Backfill support ticket history with engineering context** — Customer support platforms that previously integrated with Pivotal Tracker can use Truto to extract the full lifecycle of escalated bugs — including comments, status transitions, and linked attachments — so support teams retain complete resolution context in their own system. ## What you can build - **Full backlog import with type-aware mapping** — Automatically pull all Pivotal Tracker stories and map Features, Bugs, Chores, and Releases to your platform's native ticket types using the Unified Ticketing API's Ticket Types resource. - **Epic and iteration reconstruction** — Reconstruct Pivotal Tracker's Epics and Iterations as Collections in your product so migrated users retain their project's grouping and sprint structure. - **Historical comment and attachment archival** — Download every comment thread, screenshot, and linked file from Pivotal Tracker stories to build a searchable, immutable archive of engineering decision history. - **User and role re-mapping for team onboarding** — Pull all workspace members, their roles (Owner, Member, Viewer), and account associations via the Unified User Directory API to pre-provision teams and preserve assignee context during migration. - **Label-based release group extraction** — Import Pivotal Tracker Labels as Tags to reconstruct release groupings, feature flags, and custom categorizations that teams relied on for filtering and reporting. - **Story-level task checklist sync** — Pull the nested checklist items (Tasks) within each Pivotal Tracker story so granular sub-work is preserved and can be mapped to your product's subtask model. ## FAQs ### How do users authenticate their Pivotal Tracker account through Truto? Pivotal Tracker uses API token-based authentication. End users generate a personal API token from their Pivotal Tracker profile settings, and Truto securely stores and manages that token for all subsequent API calls. ### Is this integration read-only or does it support writes? Given that Pivotal Tracker was sunset on April 30, 2025, the primary use cases are data extraction, migration, and archival. Truto's integration focuses on reading data reliably across all supported Unified API resources. Specific write capabilities depend on whether Pivotal Tracker's API remains accessible and can be discussed on request. ### How does Truto handle pagination for large Pivotal Tracker projects with years of data? Truto abstracts Pivotal Tracker's offset-and-limit pagination so your application receives a consistent, auto-paginated response. This ensures complete extraction of large datasets — tens of thousands of stories, comments, and attachments — without dropped records. ### How are Pivotal Tracker's strict story types (Feature, Bug, Chore, Release) represented? They map to the Ticket Types resource in Truto's Unified Ticketing API. Each ticket returned includes its original type designation, so your application can apply type-aware logic during migration or reporting. ### What happens to story point estimates and backlog priority? Story point estimates and backlog rank are accessible through the Ticket Priorities resource in the Unified Ticketing API, allowing your product to preserve estimation data and prioritization order from the original Pivotal Tracker project. ### Are Pivotal Tracker tools available out of the box or built on request? Pivotal Tracker tools are built on request. Once you indicate interest, Truto's team configures the integration against the Unified Ticketing and Unified User Directory APIs, covering Tickets, Collections, Tags, Tasks, Comments, Attachments, Users, Workspaces, and more.