5

I am trying to create objects with the REST api, which works fine as long as I specify a value for each required field in the POST. The question is, how can I tell from the API which fields are required?

According to the API documentation, I should use Describe, like so:

/services/data/v30/sobjects/Account/describe/

When I do this, I get tons of metadata about the fields, but no indication as to which fields are required. I've compared required fields to optional fields and none of the metadata seems to indicated that the field is required.

Another SO thread suggested that "nillable" was equivalent to required, but that appears to be untrue. For example, Account.Name has nillable=true. I've also looked at custom objects with custom required fields, they can be nillable too. What am I missing here?

2 Answers 2

2

The way you are getting the field description is Ok:

/services/data/v29.0/sobjects/account/describe

If you check in the official doc you'll see

nillable boolean Indicates whether the field is nillable (true) or not (false). A nillable field can have empty content. A non-nillable field must have a value in order for the object to be created or saved.

I've checked Account.Name and nillable seems to be Ok:

"name" : "Account",
  "fields" : [ {
   ...
   "name" : "Name",
   "nillable" : false,

Also, I've tried two custom fields an the result are Ok:

...
   "name" : "TestReq__c",
   "nillable" : false,

   ...
   "name" : "TestNoReq__c",
   "nillable" : true,

Are you sure that your API response are getting the wrong value? Are you working with PersonAccounts?

Updated

In addition (By reading Jonathan answer) I notice, you could also check if the pageLayout using the same REST API:

/services/data/v29.0/sobjects/Account/describe/layouts

You will get there the layouts for that object where will find the layoutItem object which contains the require attr.

However, I think that you are trying to insert/update data through API and hence those security controls are expected to be omitted

8
  • I'm new to SF and I may be missing something here - I'm not sure what PersonAccount is, I think I'm just looking at Account. I definitely see "nillable":true for the field "name":"Name" when I use the /account/describe url I specified.
    – DevOfZot
    Mar 20, 2014 at 20:14
  • PersonAccounts are sort of special cases, I believe you will see a isPersonAccount field if they are. Normally, all accounts would have a Name required.
    – joshbirk
    Mar 20, 2014 at 20:18
  • @DevOfZot could you try over v29.0 version to check if you get the same result ? Mar 20, 2014 at 20:23
  • Martin, you're right, I'm creating through the api, which bypasses fields that are required according to the layout.
    – DevOfZot
    Mar 20, 2014 at 20:27
  • I tried with v29.0 and v20.0, same result. Thanks for the info, maybe it's time for me to pester some of the other SF devs here to find out if we've done something unusual to our Account object... I will try going by the assumption that "!nillable" == "required" for all fields except the Name field, and see how far that gets me.
    – DevOfZot
    Mar 20, 2014 at 20:28
2

You cannot do this with the REST API alone.

Page layouts can selectively mark fields as required. Page layouts are, I believe, only available from the SOAP API, so your application must query the SOAP API to determine which page layout is relevant for the record you're trying to create, then enforce those required fields client-side (ideally) before you attempt to upsert the record.

You must also consider validation rules and triggers, either or both of which can impose additional requirements on record saving, and neither of which is easily API-accessible for these purposes.

Ultimately I believe the only sure-fire way to test whether a record can be upserted is to actually attempt an upsert. If the upsert fails -- due to page layout, validation rule, trigger, or otherwise -- then the API response should indicate which field failed and a reason why.

Last I checked, the API will return a maximum of one failing field per upsert attempt regardless how many fields actually prevented the upsert, so you must fix the failing field it references and resubmit until the save goes through.

Edit: it's true that page layouts are ignored when saving data through the API. Ultimately it depends what kind of application you're building -- if you're building an interface that mimics the page layout on SFDC, then you'll likely want to check for (and enforce) page layout requirements.

Edit 2: Looks like page layouts are available in the REST API now. Thanks Martin :)

1
  • Thank you for the info, I'm only looking at the REST api so far and sadly all I get back is a 400 error. I guess I will dig in to the SOAP api if I have to...
    – DevOfZot
    Mar 20, 2014 at 20:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .