fieldapi/checklists/v1/:id Change in “source” Field in Response

If you have been using Field API’s endpoint: GET /fieldapi/checklists/v1/:id, you may be aware that it did not return “source” information; “source” field in response has been simply “{}”. This was because “source” was added after the API was written, there was an enhancement wish logged against it (CS-34452). The good news is that this has been implemented recently (June 3, 2019 to be exact). Now you can get this field value (y).

Field API: Updating a Equipment Creates a Duplicated Record

Q. I’m trying to update an existing equipment record. By calling /api/equipment, however, I end up creating a new record with the same values.  I used /api/get_equipment to get an equipment record, and using /api/equipment to update. What do I need to do to update an existing record?

A. Please check your JSON string representing a record and make sure that you are using “id” and not “equipment_id”. For example, if your equipment ID in JSON data looks like this:

[{“equipment_id“:”a9df893e-d9b9-4098-b434-e7d2be62d0a8”, …

then, you will need to modify it to:

[{“id“:”a9df893e-d9b9-4098-b434-e7d2be62d0a8”, …

Field API: Enforced Route Verbs

BIM 360 Field update went out today. It includes a change that potentially affects API users. As a part of pre-work for future framework update for Field, Field API’s route methods (i.e., POST, GET, PUT, etc.) used in the API calls are made strict. If you are NOT using the correct verb (i.e., the verb indicated in the documentation), you will get an 404 error. If you are using correct ones, you will not see any difference.

This made me think that we want to have a better communication channel for an update like this. The product team recognizes that, too. I did post a note to the BIM 360 API forum immediately after I heard about it. This is not just for Field. The same applies to other API, too. We will discuss with the product team to make sure we get advanced notice for any changes that have potential to break your apps in future.

Mikako

Field API: Issues Search with Two Conditions

Q. I would like to search issues with two conditions combined using this:

POST /fieldapi/issues/v1/search

For example, I want Safety Issues that were created on or after September 1, 2016.

I am able to search on a single condition. The documentation suggests like this:

"[\"cf--5bf288e4-21a0-4fe8-9a4b-67c8133fcb92,like,\\\"inspect\\\"\",\"f--status,in,[\\\"Work Completed\\\",\\\"Draft\\\"]\"]"

but I can’t get anything that resembles this to work.

Field API: max_date Parameter

When retrieving a large amount of data through Field API, we often think about performance and efficiency. If you are performing routine tasks, such as nightly sync update, one approach might be to retrieve only the data which are modified after a certain time. If you look at the Field API reference guide, there is a parameter “max_date” for some of methods. Unfortunately, the documentation lacks the detailed explanation about the format it takes. We also found that not every method with this parameter seems to work as expected. So I took a look.

Base URL for BIM 360 Field in European Countries

This week I learned that the base URL for accessing BIM 360 Field and its API for European customers is different from the one in the U.S.: i.e.,

• https://bim360field.eu.autodesk.com  <<  this is for Europe.
• https://bim360field.autodesk.com  << this is for U.S.

Notice “eu” in the URL for the first one. Obviously for the first one, the data center is somewhere in Europe, while the second in the U.S.

This means that you will need to use appropriate URL to access UI. You also need to choose a corresponding base URL to use the REST API. You cannot switch projects between the different servers.

Adding High Level Category to Issue Types

Q.  Is there a way to add a new high level category to the issue type using Field API?

A.  Please try:

POST /fieldapi/issues/v1/create_type

This method takes a name of category and a name of issue type:

• ticket
• project_id
• category_name – string. The name of category (e.g., Punch List, Safety)
• name – string. The name of issue type within the category. (e.g., Observation, Concealment Work to Complete).

Retrieving Issues for Equipment

There is a small API enhancement that was made available in the latest update of BIM 360 Field. It allows you to retrieve a list of issues related to a given equipment.

POST /fieldapi/issues/v1/search request has two additional parameters, source_id and source_type:

• source_id – an id of source object, i.e., task or equipment, whose issues you would like to retrieve.
• source_type – a type of source/parent objects, i.e., “Task” or “Equipment”.

Using these parameters, the following request will return all issues under equipment including all issues coming from checklists attached to the equipment with one call:

/api/get_equipment details Parameter Explained

Field REST API call, /api/get_equipment, allows you to retrieve equipment records. It has a parameter “details” which, in the API reference page, read as follows:

details : string – Whether to retrieve equipment details, or just header information (e.g. ‘some’, ‘more’, ‘none’)

I find this description vague. From an internal discussion, I learned that there is details = ‘all’ option as well, which isn’t documented. So I decided to experiment these options for details parameter. I thought sharing my observation here with sample outputs might clarify the meaning of these options.

BIM 360 Field Administration Feature Enhancement

If you are a BIM 360 Field account administrator, you may have received a notification e-mail titled: “Important information about your Autodesk BIM 360 Field account”. The Field product team is releasing updates with new features which require customer-by-customer-base updates. The changes are around administration feature. Account and Project administration areas are redesigned, and have clear distinction between two types roles to help streamline administrative tasks:

• Account administrator can create projects and assign project administrators who will grant their project members access to models and data. An account administrator is typically an employee of the general contractor or owner organization, such as the IT manager.
• Project administrator can invite/edit/remove project members.  (Project creation is by account admins mentioned only.)