Project Online API vs Onplana: Integration Capabilities Compared
Project Online API is read-heavy by design and rarely supports writes. Here is how each tool compares for common PMO integrations, webhooks, and automation.
Most Project Online integration documentation focuses on reading data. The OData feed is well-documented, the Power BI connector works reliably, and a developer who understands the entity relationships can pull project status, resource assignments, baseline comparisons, and timesheet data into virtually any downstream system.
The harder problem surfaces when an integration needs to write data back into Project Online. Creating a project from an external system, updating task status from a field worker's mobile app, syncing assignments from an HR system when a resource joins or leaves a project: these are the patterns where the Project Online API shows its age, and where many integrations that look straightforward on the whiteboard turn into multi-week development efforts.
Project Online API integration is split across two interfaces: the OData reporting endpoint (read-optimized, well-documented, limited by per-entity page sizes) and the CSOM (supports writes but has coverage gaps, a 2 MB request size limit, and a queue-based execution model). Webhooks require hosting a custom event receiver. Onplana ships a full REST API with CRUD across all major entities, webhooks for event-driven integration, and Personal Access Tokens for simpler service authentication. For read-heavy integrations (feeding a BI tool, syncing status to a ticketing system), both tools work well. For write-heavy integrations (creating projects from another system, syncing updates bidirectionally), Onplana's API is substantially less constrained.
The Project Online API landscape
Project Online exposes three integration interfaces, each with a different purpose and different constraints.
The OData reporting endpoint. Accessed at /_api/ProjectData/, this is the most commonly used interface for integrations. It exposes reporting data: published project state, resource assignments, timesheet summaries, baseline comparisons. The data is read-only. You can filter, sort, and page through the data using OData query options, but you cannot make changes through this endpoint. Per-entity page limits apply (300 projects, 1,000 resources, 300 tasks per query by default), which requires pagination strategies for large tenants. The endpoint is well-documented and widely used, particularly for Power BI connectivity.
The CSOM (Client-Side Object Model). The CSOM is the developer interface for Project Server and Project Online that supports write operations. It covers the 12 most commonly used PSI services: creating and updating projects, tasks, assignments, and resources; managing custom fields and lookup tables; handling timesheet operations. The CSOM operates through a SharePoint-based request model with a 2 MB size limit per operation batch and a 50 MB limit for binary objects. Because Project Online queues write operations, changes do not execute synchronously: you submit a request, the queue processes it, and you poll for job completion. For large-scale automation (creating 50 projects from a project intake system), the queue model and size limits require careful batching logic.
Remote event receivers. Project Online can fire remote event receivers on specific events (ProjectCreating, ProjectPublished, StatusUpdated). These are the closest equivalent to webhooks, but they require hosting a service endpoint accessible from the Microsoft cloud, registering the receiver against specific Project Online events via the PSI or CSOM, and managing the lifecycle of the receiver registration. The implementation overhead is substantial compared to subscribing to a modern REST webhook.
Microsoft's own documentation on what the CSOM does and does not do covers the coverage gaps in detail: administrative settings, archive operations, OLAP cube management, and business driver workflows for portfolio analysis are not available through the CSOM and require the lower-level PSI services.
What the Project Online API does and does not support for writes
The coverage gaps in the CSOM matter most for the integration patterns PMOs actually need.
What works reasonably well: Creating projects programmatically from a project intake form or external system. Reading and updating task completion percentages. Adding and removing resources from projects. Creating and submitting timesheets. Managing custom field values on projects and tasks.
What requires additional complexity: Updating task assignments without triggering unwanted schedule recalculations (the queue-based model means you have to sequence operations carefully). Creating projects with custom Enterprise Project Types (EPTs), which requires knowing the EPT GUID and managing the phase-gate workflow state. Writing to the reporting tables directly (not possible; changes go through the project data layer and publish to reporting on the next sync).
What is not supported at all through CSOM: Creating or modifying PWA permission groups and categories (requires PSI Security service). Managing governance workflows beyond basic phase/stage transitions. Administrative operations like creating fiscal periods or modifying timesheet settings. Archive and backup operations.
For many common PMO integration patterns (syncing project status to a Slack channel, feeding project completion data to a BI warehouse, creating a project when an opportunity is won in CRM), these gaps do not matter: the integration is read-heavy and the OData endpoint covers it. For bi-directional integrations or integrations that need to create and configure projects programmatically with full EPT and governance setup, the constraints add significant complexity.
Authentication in Project Online integrations
Production integrations against Project Online require OAuth 2.0 authentication via Azure Active Directory (now Entra ID). The integration registers an Azure AD application, requests the appropriate Project Online API permissions (ProjectWebApp.FullControl or scoped permissions), and obtains tokens via the OAuth client credentials flow for service-to-service scenarios or the authorization code flow for user-delegated scenarios.
This setup requires a Global Administrator or Application Administrator in the Microsoft tenant to consent to the permission grant. For PMOs in organizations with strict IT governance around Azure AD application permissions, getting consent approved can add weeks to an integration project. The permissions model is also coarser than many PMOs prefer: granting ProjectWebApp.FullControl gives the integration read-write access to all PWA data, with no option to scope to specific projects or custom fields.
Token expiration and refresh is another operational concern. Access tokens issued for Project Online have a one-hour lifetime; integrations must implement token refresh logic or accept re-authentication failures. For integrations that run infrequently (weekly batch jobs, monthly reporting), expired tokens are a common source of integration failures that surface only when someone notices the data stopped updating.
What Onplana's REST API ships
Onplana's API is a standard REST interface with JSON payloads, covering full CRUD operations across all major entities: projects, phases, tasks, assignments, resources, custom fields, governance stages, risk records, and issue records.
Authentication options: Personal Access Tokens (PATs) for service accounts and integrations, OAuth 2.0 with PKCE for user-delegated flows, and SSO provider integration for organizations using Okta, Entra ID, or Auth0 as their identity provider. PATs are the simplest path for integration scenarios: a PMO administrator creates a PAT scoped to specific resource types (read-only for reporting integrations, write access for systems that need to create or update records), and the PAT is used as a bearer token without OAuth redirect flows or token refresh complexity.
Write operations: Creating a project via the API requires a single POST request with the project name, template reference, and initial custom field values. The response is synchronous: the project exists and is ready for subsequent requests immediately, with no queue to poll. Task creation, assignment updates, and resource modifications follow the same pattern. There is no batch size limit that requires custom pagination logic for typical integration workloads.
Webhook subscriptions: Onplana's webhook system lets integrations subscribe to specific events: project.created, project.status_changed, task.completed, baseline.saved, governance.gate_approved, and others. Webhooks deliver event payloads to a configured HTTPS endpoint, signed with HMAC-SHA256 for verification. The delivery model is push-based: the integration receives a POST request when the event fires, rather than polling an endpoint on a schedule.
Webhook and event-driven integration patterns
Event-driven integrations are where the architectural difference between the two tools becomes most visible in practice.
A common PMO integration need: when a project reaches the "Authorization" governance gate and gets approved, automatically create a channel in Teams, provision a SharePoint site, and notify the assigned PM. In Project Online, implementing this requires a remote event receiver registered against project workflow stage events, a hosting service for the receiver endpoint, and coordination with the SharePoint workflow infrastructure that, as documented in the governance comparison between Project Online and Onplana, has been broken since April 2026 for tenants relying on SharePoint 2013 workflow engines.
In Onplana, the integration subscribes to the governance.gate_approved webhook event for the Authorization stage. When the gate approves, the webhook delivers a payload to the integration endpoint with the project ID, gate name, approving user, and timestamp. The integration service receives the event and triggers the downstream actions. No hosted receiver infrastructure is required; no workflow engine dependency is involved.
The diagram below shows the integration architecture for each tool for this common event-driven scenario.
Project Online API vs Onplana: feature comparison
| Integration capability | Project Online | Onplana |
|---|---|---|
| Primary read interface | OData (REST, JSON or Atom) | REST API (JSON) |
| Primary write interface | CSOM (.NET, JavaScript, REST) | REST API (JSON) |
| Write operation model | Asynchronous queue (poll for completion) | Synchronous (immediate response) |
| Request size limit | 2 MB per CSOM batch | No fixed limit for standard operations |
| Pagination required | Yes (300 projects, 1,000 tasks default per query) | Yes (configurable page size) |
| Webhook support | Remote event receivers (complex setup) | Native webhooks (subscribe via API) |
| Event signature verification | None built in | HMAC-SHA256 |
| Authentication methods | OAuth 2.0 (Azure AD, admin consent required) | PAT, OAuth 2.0, SSO provider |
| API coverage for writes | Partial (CSOM covers 12 of 17 PSI services) | Full CRUD across all entities |
| Governance event triggers | Via PWA workflow events (SP 2013 workflows retired) | Native governance webhook events |
| Rate limiting | Tenant-based throttling (SharePoint limits apply) | Per-key rate limits (documented) |
| SDKs available | .NET, JavaScript, CSOM | REST (any HTTP client), no SDK required |
Common integration use cases
Project creation from a CRM or intake system. When a sales opportunity is won, create a project in the PM tool with the client name, project type, and assigned PM. In Project Online: requires CSOM, Azure AD app registration with admin consent, awareness of the EPT to use, and handling of the asynchronous queue response. In Onplana: a single authenticated POST to /api/projects with the project body; the project is available immediately for subsequent assignment operations.
Status sync to a ticketing system. When project milestone status changes, update the corresponding Jira epic or ServiceNow record. In Project Online: requires a polling integration against the OData feed, comparing milestone status timestamps to detect changes, since there is no reliable event push. In Onplana: subscribe to the milestone.status_changed webhook event; the integration receives a push whenever a milestone state changes.
Resource sync from HR system. When a new hire is onboarded or a contractor's engagement ends, update the resource pool in the PM tool. In Project Online: CSOM QueueUpdateResources with the resource GUID, followed by polling for queue completion. In Onplana: PATCH request to /api/resources/{id} with the updated fields; immediate response confirmation.
Timesheet data export to payroll or ERP. Pull weekly timesheet actuals for cost reporting. Both tools support this pattern well. Project Online's OData endpoint exposes TimesheetLineActualDataSet with configurable filters. Onplana's REST API exposes timesheet actuals with equivalent filtering capability. For read-only export scenarios, the two tools are roughly equivalent in complexity.
Migration considerations for API-dependent workflows
Integrations are among the highest-risk components in a Project Online migration, largely because they are often invisible in migration planning. The Project Online migration checklist addresses data migration (projects, tasks, resources, baselines) in detail, but API-dependent workflows are rarely inventoried with the same rigor.
Before migration, catalog every integration that touches Project Online. Specifically identify: which use the OData feed for read operations, which use CSOM for write operations, which are polling-based versus event-driven, and which are maintained versus abandoned. For integrations built two or three years ago that nobody has touched since, determine whether they are still in use before investing migration effort in them.
For integrations being rebuilt against the destination tool, the migration window creates a sequencing challenge: the integration needs to be rebuilt and tested before the Project Online cutover, but it cannot be validated end-to-end against production data until after cutover. Building against a test environment first and validating against production data in a 48-hour parallel-running window is the lowest-risk approach. The security and compliance considerations for API credentials are particularly relevant here: any integration using service account credentials tied to the old tenant needs credential rotation as part of the cutover, not after.
For organizations with complex integration portfolios, the integration migration often represents more elapsed time than the data migration itself. Building in a 4-6 week integration validation phase before cutover day is not conservative; it is the median experience in PMO migrations where integrations exist.
The Onplana features page documents the full API and webhook capability set for reference when scoping the rebuild effort.
Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.