Unified.to
All articles
·

Unified Performance Management API: Read and Write Goals, Reviews, and Feedback Across Performance Platforms


August 13, 2026

Unified now supports a new category: Performance Management.

The Unified Performance Management API gives you one performance API to read employee goals, review cycles, performance reviews, and feedback, and to write goals and feedback, across the performance platforms your end-customers already run. Every request is routed directly to the customer's platform at the moment you make it, so what you read is what exists in their platform right now. Nothing is cached and no end-customer data is stored.

Object and field coverage differs by integration, because each platform's own API determines what Unified can support. Field support, webhook support, and list parameters are documented per integration.

What is a performance management API?

A performance management API reads and writes employee goals, review cycles, performance reviews, and feedback from the platforms where that data lives, whether that's a dedicated performance platform like Lattice or 15Five or an HRIS like BambooHR or HiBob that carries performance data alongside employee records. The Unified Performance Management API serves all of it through four normalized objects with the same field names across every integration, so the goals module or review product you build once runs against whichever platform each customer happens to use.

Why is performance management its own category?

Performance data serves a different set of products than core employee records, and buyers evaluating a performance integration search for it by name. HR & Directory covers the system-of-record data: who works here, on what terms. Performance management covers how they're doing against goals, which is its own vertical of B2B software, from review platforms to engagement analytics. Carving HR verticals into their own categories is established practice in this market: Kombo and StackOne both run LMS as its own API outside HRIS, and Kombo separates Assessments the same way. Performance data hasn't had that treatment: where unified API vendors support it at all, it sits as objects inside the HRIS model, the way Kombo models performance reviews and review cycles within its HRIS API. Unified's Performance Management category gives that data its own API surface: four objects, goal and feedback writes, and a per-integration capability matrix.

What changes when you build against one performance API

Each performance platform models goals, cycles, reviews, and feedback in its own API, with its own names, shapes, and person model, so supporting a second platform natively means building and maintaining a second integration. Against the Unified Performance Management API, the second platform is the same four objects on a different connection.

Building per platformBuilding on Unified
Integration workA separate integration for each platformOne integration against four normalized objects
Data modelEach platform's own names, shapes, and identity modelGoal, Cycle, Review, Feedback with the same field names across integrations
IdentityA different person model per platformuser_id references to the HRIS employee object on reviews, feedback, and goals
WritesEach platform's own create and update semanticsCreate, update, and remove goals; create feedback; the same request shape across integrations
AuthorizationSeparate auth and scopes per platformUnified's authorization component, one connection per end-customer
Data freshnessWhatever your sync interval isUnified pass-through architecture: requests are executed directly against the source API on each call
MaintenanceRework each integration when its API changesSchema changes absorbed behind the unified objects
CoverageWhatever you build, on the platforms you build forDocumented per integration and per field

What you can build with the performance management API

  • Goals modules that read a customer's existing goals and OKR trees instead of asking employees to re-enter targets, and write updates back as progress changes
  • Review and calibration products that read self, manager, peer, and upward reviews with ratings, the scale's maximum, and every question's answers in one request
  • Recognition products that post praise with company-value tags and respect each platform's visibility model, from public praise walls to manager-only notes
  • Compensation planning that reads goal attainment and review ratings alongside the employee records your HRIS integrations already return
  • Engagement analytics that correlate feedback volume and goal progress across a customer's whole company
  • AI agents that read goal progress and review outcomes at request time to draft a check-in or recommend a next step

The last one is why this category matters for AI products specifically. An agent preparing a manager for a 1:1 needs the goal as it stands at the moment of the call. A goal copied overnight is a guess about the present.

Which performance platforms does Unified support?

The Performance Management category covers 7 integrations:

  • 15Five
  • BambooHR
  • Engagedly
  • HiBob
  • Lattice

What objects does the Unified Performance Management API normalize?

The performance API provides four normalized objects:

  • Goal — a target at individual, team, department, or company level, with a progress percentage, a weight for when the platform weighs goals in reviews, a parent_id for OKR trees, user_ids where the first entry is the primary owner, a pointer to its cycle, and a milestones array where each milestone or key result carries a target value, current value, unit, weight, and completion state
  • Cycle — a review cycle or goal timeframe, with a type distinguishing the two, a status running draft, scheduled, active, closed, and start, end, and due dates
  • Review — a self, manager, peer, or upward evaluation, with the rating, the maximum on the platform's scale, the scale's label such as "Exceeds expectations", the summary comment, a questions array carrying each question with its type and all answer values, acknowledgement state, and submission and completion dates
  • Feedback — praise, constructive feedback, or a response to a feedback request, with the author, the recipient, tags for badges or company values, and an is_visible flag separating a public praise wall from private or manager-only notes

Milestones and review questions are structured data inside their parent objects rather than separate endpoints. One request to a goal returns its milestones with quantified progress against each target; one request to a review returns the questions and answers alongside the rating. If you're scanning a comparison for a key results or review questions resource, at Unified they're fields on the goal and review objects, not separate objects to fetch and join. That's a property of the schema; whether a given field returns data depends on what each platform's own API provides, and the capability matrix documents it per field.

Unified normalizes the shared concepts and provides access to platform-specific fields through the raw field on every object.

What can you write, and what happens to a write?

Goals support create, update, and remove; feedback supports create. Cycles and reviews currently support retrieve and list, and method support extends as the category does, so the docs are the current source for what each object supports.

Which objects and fields are writable on which integration is in the capability matrix, and write support is narrower than read support, as it is across every HR category: platforms guard writes on performance data more tightly than reads, and a unified layer inherits every one of those rules. Check the matrix against the platforms your customers actually run.

A write matters more here than in most HR data, because a review process is interactive: feedback gets submitted after a 1:1, a goal gets updated during a check-in, and both sides expect the platform of record to reflect it immediately. When your application creates a goal through Unified, the write is executed against the source platform directly. On a cache architecture, that write lands in the vendor's database first, and many first-generation unified API vendors will hold it for up to a day before it reaches the source. Until it does, your product says the goal changed and the platform the HR team is looking at says it didn't.

How performance data connects to the rest of the HR cluster

The user_id on reviews and feedback and the user_ids on goals are references to the HRIS employee object, so a product already reading employee data through the HR & Directory category joins goal attainment or review ratings to the same identity without a second employee model. That's how the HR cluster is built generally: categories don't each carry their own employee model, they reference the one that HR & Directory serves.

That matters because a performance product is rarely a one-category product. Manager and upward reviews presuppose reporting lines, cycle eligibility runs on start dates, and goal rollups follow the org structure — all of it employee data your product reads through HR & Directory, which spans 451 integrations with a published per-integration capability matrix. One customer authorization serves both categories on the same connection.

Performance Management joins the categories Unified runs across the employment lifecycle, on the same pass-through architecture: ATS, Assessments, Verifications, Learning Management, and HR & Directory. A candidate hired through the ATS becomes an employee in the HRIS, gets background-checked, provisioned, and onboarded into training — and now reviewed against goals once they're working. Each handoff runs through the same authorization components, with no stored records anywhere along the way.

How you read performance data

Every performance object is listed at GET /performance/{connection_id}/{object} and retrieved at GET /performance/{connection_id}/{object}/{id}, so the request shape is the same whichever object you are after and whichever platform the connection points at.

List requests take limit and offset for paging and updated_gte to return only records changed since a timestamp, which is what makes an incremental read possible without a stored cursor. Each object adds the filters its shape calls for: user_id on goals, feedback, and reviews to read one employee's records; parent_id on goals to read an OKR subtree; and cycle_id on reviews to read one review cycle's evaluations. Parameter support per integration is in the capability matrix, the current source as coverage extends.

Which changes can you receive as webhooks?

Unified detects changes on all four performance objects and delivers events to your endpoint, so a product can react to a change rather than poll for it. The available events are performance_goal_created, performance_goal_updated, performance_cycle_created, performance_cycle_updated, performance_review_created, performance_review_updated, performance_feedback_created, and performance_feedback_updated.

Support varies by integration: as of August 2026, performance webhook events are available on 15Five, and the remaining integrations in the category read on a schedule you set. There are no deleted events in the performance category as of August 2026. Webhook support per integration is documented in the capability matrix, which is the current source as coverage extends.

Example build

A goals module inside your product, so a customer's employees see and update their goals without leaving it:

  1. Each customer authorizes their performance or HR platform through Unified's authorization component. You store one connection ID per customer.
  2. You list Goal objects for that connection and render each with its progress, status, and milestones, showing quantified progress where the platform returns target and current values.
  3. You render OKR trees from parent_id and shared ownership from user_ids.
  4. When an employee updates progress, you update the goal through Unified and the write is executed against the customer's platform.
  5. Where the integration supports it, you subscribe to performance_goal_created and performance_goal_updated so the module reflects changes made in the customer's platform without you polling for them; elsewhere, you read on a schedule you set.
  6. You join goals to the employee records your HRIS integration already returns, through the same user_id references.

The same code runs against every customer. What varies is how much detail each platform returns, not whether the feature works.

Real-time by design

Every request is executed directly against the source API rather than served from a stored copy.

Requests are stateless. No end-customer performance data is cached, synced, or stored at rest on the request path. That matters more in this category than most: performance reviews carry ratings, manager comments, and private feedback, some of the most sensitive records in the HR cluster, and they stay inside the platform the customer already chose.

The Performance Management API is one of 33 categories and 874 integrations on Unified, and is available on all plans.

Start your 30-day free trialBook a demo

Frequently asked questions

What is a unified performance management API?

A unified performance management API provides one interface for reading and writing employee goal, review, and feedback data across multiple performance platforms. Instead of building against Lattice, 15Five, and BambooHR separately, developers integrate once and work with the same object names and fields regardless of which platform an end-customer runs.

Which performance objects and fields are supported on which platforms?

Coverage differs by integration because each platform's own API determines what Unified can support, and it changes as integrations are added and extended. The Supported Integrations page lists field support, webhook support, and list parameters for every integration in the category, and is the current source rather than any figure quoted elsewhere.

Can I write performance data, or only read it?

Goals support create, update, and remove; feedback supports create; cycles and reviews currently support retrieve and list. Which fields are writable on which integration is in the capability matrix, which is the current source as method and field support extend, and write support is narrower than read support because performance platforms restrict external writes. Writes are executed directly against the customer's platform rather than applied to an intermediate copy.

Do existing connections work with the performance category, or do customers need to authorize again?

What gates a connection is the scopes granted when the customer authorized, not the category. Connections authorized with the default permission behaviour, which requests every scope the integration offers, already carry what performance reads and writes need. Connections authorized with narrow permissions may need the customer to authorize again with the added permissions; credentials are permission-tested at authorization, so a scope gap surfaces there rather than in production. For API-key integrations, access is bounded by what the key itself permits.

Does Unified store performance review data?

No. Unified does not store end-customer data at rest on the request path. Each request is executed directly against the customer's platform and the response is returned without being cached or written to a database, which keeps ratings, review comments, and private feedback inside the platform the customer already chose.


Author

Written by Mallory Greene

Mallory Greene is Head of Marketing at Unified.to. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto.

All articles