Community
Showing results for 
Search instead for 
Do you mean 
Reply

Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Accepted Solution Solved
Copper Contributor
Posts: 32
Country: Germany
Accepted Solution

Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Good afternoon,

 

I'm trying to access products / services through the WebAPI, but I'm not happy with the result so far. Try as I might, I can't get it to show the custom fields. All I get are the standard fields.

 

{ "id": "someID",

"name": "someName",

"cost": 0,

"createDate": "2018-03-01T11:12:50+01:00",

"discount": 0,

"discountPrice": 1.9,

"editDate": "2018-03-23T15:53:05+01:00",

"itemNumber": "someItemNumber",

"opportunityID": "someOppID",

"price": 1.9,

"productID": "00000000-0000-0000-0000-000000000000",

"quantity": 1,

"total": 1.9 },

 

 

The items were added by simply clicking "Add item" within the Opp, so not throught the product list.

 

Any help much appreciated.


Accepted Solutions
Solution
Accepted by topic author Thomas_Benn-MS
‎04-27-2018 05:44 AM
Employee
Posts: 70
Country: USA

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Released a new API v.1.0.265.0 that will fix this issue:  However, if you are on Act Premium cloud, it will be released Friday night.

 

You can download from these sites:

 

    https://www.act.com/download/download-act!-premium-v19

    https://www.act.com/download/download-act!-premium-v20

 

The Type (item_type) is included in the customFields now, the API was not able to add it to a model, but it will always show in custom fields.

 

View solution in original post


All Replies
Copper Contributor
Posts: 32
Country: Germany

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

BTW, the standard field "type" is missing as well (it's called "itemtype" in the SQL db).

Copper Contributor
Posts: 32
Country: Germany

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Is there any more information I could provide? I'd really like to get an answer to this.
Administrator
Posts: 1,372
Country: United_Kingdom

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Hi Thomas,

I've raised this query to our API Dev team - so we should have an answer soon.

Thanks for your patience!
Copper Contributor
Posts: 32
Country: Germany

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Thank you Jonny.
Administrator
Posts: 1,372
Country: United_Kingdom

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

The API team are looking at this issue now, it looks like Opportunity Products don't currently have mappings for custom entities - but they should.

Hopefully, they'll be able to build this functionality into a upcoming release quite quickly.
Copper Contributor
Posts: 32
Country: Germany

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Sounds great. Thank you.
Solution
Accepted by topic author Thomas_Benn-MS
‎04-27-2018 05:44 AM
Employee
Posts: 70
Country: USA

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Released a new API v.1.0.265.0 that will fix this issue:  However, if you are on Act Premium cloud, it will be released Friday night.

 

You can download from these sites:

 

    https://www.act.com/download/download-act!-premium-v19

    https://www.act.com/download/download-act!-premium-v20

 

The Type (item_type) is included in the customFields now, the API was not able to add it to a model, but it will always show in custom fields.

 

Copper Contributor
Posts: 32
Country: Germany

Re: Custom fields missing in GET /api/opportunities/{opportunityId}/products/{id}

Since it's kind of a follow-up to this, I'll post this here.

Please try this:
Create a new field under "Products". Afterwards, rename the field. Then, call the product list for any Opp via
/opportunities/{id}/products
and, voila, the field you created is still listed under its original name, not under the new name.

Same is true for other areas (contacts, etc).
We believe that the WebAPI works on the "internal" name of the field (starting with "cust_") and not the "display" name of the field (although, fields with blanks in the names kinda contradict this theory).

Either way, this makes custom fields a bit hard to use reliably, since any changes in the naming wouldn't reflect in the WebAPI.

Thoughts?