Skip to main content
This guide adds an asset to the register, then corrects it, moves it and changes its status. The examples assume a token in $TOKEN (Authentication) and a site to put the asset at (Add a site).

Find the ids you need

An asset needs three things: a name, a category and a site. The category and site are sent as ids. Find the category by searching for it:
If you already know the category’s code, filter the list by it instead: /asset_categories?select=id,code,name&code=eq.PUMP-CENT. Find the site the same way, with /sites?select=id&code=eq.<code>.

Add the asset

Call create_asset with the asset’s fields in p_values:
The answer is the new asset. Its number comes from your organisation’s numbering and its status is the first one in its lifecycle, so you send neither:
The Add an asset page under Integration API lists every field p_values accepts, with what each one means. Some you will often want: Your organisation’s own fields go in p_custom_fields, keyed by the field’s key. The keys are your organisation’s, so production_line here stands for one of yours:

If it is refused

A field the register does not have, or a required one left out, is refused before anything is written:
Errors explains the rest.

Read it back

Correct it, move it, change its status

update_asset refuses a change of site or location with MOVE_INSTEAD. Moving an asset is move_asset, which keeps a record of where the asset came from. Putting an asset into a closed status, such as disposed, cancels the open work against it, and the answer lists what was cancelled. Your organisation can ask for more before some statuses. In the demo organisation an asset needs a custodian before it becomes active, so transition_asset to ACTIVE is refused with CUSTODIAN_REQUIRED and "fields": ["custodian_user_id"] until one is set with update_asset.
Next: raise and complete work against the asset.