We need to be able to set values in custom fields in Commitments via the API and this is not available today.

Implement OData within API

This would allow API Users quicker and easier querying and retrieval of specific data entities with less calls to the API.

Allows for easier access to project data with fewer http calls.

Need to retrieve list of open items per project and per user.

adding `potential_change_order_ids` array to the COP response params this way you can avoid all those steps and go directly to the PCO to create the line items.

That way we could have our Procore Workers list automatically update every day to match what our accounting system lists as our current list of employees.

Include Drawing Title, Drawing Number, and other meta data fields in the Drawing Upload API, so that the OCR and review process can be skipped. We already have all the data that the OCR attempts to gather, so we'd like to be able to automatically include it in the upload through the API, and avoid the time-consuming effort of teaching and reviewing the OCR outputs.

Requisitions have a paltry number of fields to put text into. Overall Comments is something we could use, but it is not exposed for reading nor writing via the API. Please add this, as we will use it to put ERP information to help reconcile data. I'm sure others will find it useful as ewll.

We have a need to report on metrics involving Drawings, including the number of drawings uploaded to a project. When a drawing is deleted form a project, our reporting is unable to capture it. We need a way to accurately report on this, to include deleted drawings.

Currently only Drawing Aera, Drawing Set and Drawing has trigger support.

It would be nice to have Drawing Revision support since we can get notified with a specific created/updated Drawing Revision event rather than inspecting a vague Drawing update event.

I'd like to have the ability to prevent apps from being authorized to access our data via the API. We want to remove the possibility of compromising our data since any user can authorized apps to read our data without Company Admin/IT knowledge.

Restrict Access to the API based on a Directory Permission Setting.

It is important to load Vendors when integrating financial data. Of all the API endpoints, Vendors load seems to be the slowest. There is a Compact load, but that is not useful since it only has the vendor name and Id number. We need the origin_* fields in order to use this data in integrations. Please add these to the compact load so we can load vendors faster without having to get all the other vendor information.

Add Origin_ID, Origin_Code, and Origin_Data fields to Vendors Compact Load

As a subcontractor, tracking submittals and RFIs that are from another subcontractor or the general contractor. Currently, the database only allows for tracking of your own submittals and RFIs. The logs will only track the Nibbi Concrete authored Submittals and RFIs.

We need the ability for all Project Home Configuration settings from the template to be copied over to a new project (including iFrame settings and persistent project message) through the API.

We need to be able to sync attached vendor documents between systems.

It would be great if we had access to our database on ProCore, this way we could create our own templates to import into our accounting software. We currently use ComputerEase for our accounting software, Procore for daily time tracking and subcontract commitments. We are having trouble getting the two to communicate. If we had access to our data base we could generate our reports using Crystal report writer or access to import into Computer ease

Compatibility between Procore and Primavera's P6 Cloud Connect.

For integrations it is very helpful to know when a budget line item was last modified. Please add this to the API. Last Modified date is generally useful on any API response, and any database table for that matter.

When we create an item via the API, I would like to be able to choose which workflow is used on the object. Here is the case:
- when a user creates the item, the standard workflow should happen
- when our integration creates an item, it should use a integration-specific workflow.

The standard workflow will send off emails as normal. The integration workflow will not deluge users with emails as it creates 100's or 1000's of items.