Object Identifiers

As with many enterprise application, internal objects are often assign an object identifier, oid for short, that is unique to each object of a given type. Throughout the REST API specification you will see pairs of fields that provide the object identifier as well as the human friendly identifier. Let's take a look at ItemShippingPackageRequirement model. This model contains two fields:

• package_name
• package_oid

If you're trying to assign a package to an item for shipping then you're going to need to create an ItemShippingPackageRequirement object.
You may not know the oid of that particular package object, but that is OK. You can just specify the name and the system will automatically resolve the oid value. Don't make a value for an OID or set it to zero. You will receive an error back from the server.

Another scenario is removing an identifier to a child object during an update. Take the ItemAutoOrder model for example which has the following fields:

• auto_order_cancel_item_id
• auto_order_cancel_item_oid

When configured, this setting tells the system to charge the customer with a given item, typically a cancellation fee, when they cancel their auto order.
If you want to remove this setting with a REST API call, you will need to null out BOTH fields before making the update. The oid field is what the system truly cares about, but if you null only that field then the system will resolve the oid using the companion field such as auto_order_cancel_item_id.