Entities
Once you've configured your API instances, you can start making requests to retrieve and manipulate Entity records.
Here are a few examples on how to retrieve one or many Entity records.
Here is how you can update or create Entity records.
API responses typically include trace, warnings, and errors alongside the returned data. For singular Entity requests, these are available under the Bruce property, for lists they are available at the root level as the Entity data is underneath the Items property.
Reading and writing attribute values
Attribute paths are quoted and slash separated, which is what lets a single segment contain a dot or a space. BM.PathUtils converts between that form and a plain list, and the value helpers walk a record for you rather than making you index into nested dictionaries.
A missing attribute reads as None. A stored 0, empty string or False is returned as-is, so you can tell an empty value apart from an absent one.
Where the data came from
When an Entity draws attributes from external sources, its internal data carries an Outline describing which source contributed what. It arrives on its own for a request by ID, or when an Entity Type is part of the filter, so there is nothing to enable.
The baseline entry is where the record itself came from, and the remaining entries list the attribute paths each source supplied. Sources that are not editable should not be offered for editing in your own tooling.
Historic data
Entity Types configured with historic data keep previous values against a date/time. Pass a point in time and the nearest matching historic record replaces the Entity contents. If nothing matches, the current record is returned unchanged.
A historic read reports itself in the Outline described above, as another source among any others. That entry carries the DateTime the values came from, and a ForeignKey naming the attribute the date/time was read from.
Historic records directly
Overlaying a point in time answers "what did this Entity look like then". To work with the records themselves, reading a series or writing one, use BM.EntityHistoricData. It covers the whole surface, so there is no need to pick between endpoints.
A record is shaped like the Entity it belongs to: your attribute values sit at the root of Entity, and platform managed values such as the location sit under its Bruce key. That means the same object comes back from a read as goes into a write.
Before paging through a long range, ask where records actually exist. get_analysis returns counts across the matched range rather than the records themselves.
Writing a record is how you add history the platform did not capture itself, such as a backfill from another system. build_record assembles one, wrapping the attribute path and nesting any platform managed values.
Note that the date/time attribute named by attr_key should also be present in the values, since that is the attribute the record is keyed on.
There are two ways to delete. Hand back the records you read to remove exactly those, or describe a range with the same filter a read takes.
A record is identified by its Entity, its attribute and its date/time together, which is why a record read back is enough to delete it.
Every one of these accepts a scenario, so a series can be read, written or cleared inside a Scenario without touching the real world records. A Scenario identifies its own records, so writing into one makes the date/time and attribute optional.