Writing Back Safely: Creating and Updating Records

The same safety boundary, a new place it applies

Read-before-write didn't stop mattering

APIs and REST for Network Engineers (Phase 3.1) taught reading before writing as a safety boundary for device changes. A NetBox record isn't a device -- but if automation trusts it as a source of truth, a wrong write here is just as real a mistake as a wrong device config. The same discipline applies.

Record's real write methods, installed pynetbox 7.8.0

Record.save(self)
Record.update(self, data)
Record.delete(self)

Verified via inspect.signature against pynetbox.core.response.Record -- the object type every query in Lesson 3 already returned.

Quick checkConcept check

Why does this lesson explicitly connect back to Phase 3.1's read-before-write principle?

It doesn't apply here -- NetBox writes are always safeA NetBox record being wrong is just as real a mistake as a device misconfiguration, if automation trusts that record as its source of truth -- the same read-before-write discipline that protected devices now protects the data those devices are modeled frompynetbox automatically prevents all write mistakesThis principle only ever applied to Ansible's check mode

Creating a record: real, verified

verify_pynetbox_write.py -- real, executed

new_device = nb.dcim.devices.create(name="SW4", serial="SW4-SN-004")
print("created:", new_device.id, new_device.name, new_device.serial)

Endpoint.create() -- verified via inspect.signature to accept the same *args/**kwargs shape as filter()/get().

output — real, verified

created: 100 SW4 SW4-SN-004

Real, verified output. The mock backend assigned a real new id (100) and returned the created record, exactly matching NetBox's real documented create response shape (HTTP 201 with the new object).

Quick checkIdentify the correct code

Which correctly creates a new device record via pynetbox?

nb.dcim.devices.create(name="SW4", serial="SW4-SN-004")nb.dcim.devices.new(name="SW4")nb.dcim.devices.add("SW4")nb.dcim.devices["SW4"] = {}

Updating a record: real, verified, and re-read to confirm

real, executed — update, then re-fetch to prove it persisted

sw1 = nb.dcim.devices.get(name="SW1")
sw1.update({"serial": "SW1-SN-001-UPDATED"})

sw1_again = nb.dcim.devices.get(name="SW1")
print("re-fetched serial:", sw1_again.serial)

Not just trusting update()'s return value -- a fresh get() call afterward proves the change actually persisted on the backend, the same reread-to-confirm discipline used throughout this curriculum.

output — real, verified

update() returned: True
sw1.serial after update: SW1-SN-001-UPDATED
re-fetched serial: SW1-SN-001-UPDATED

Real, verified output across all three checks -- the update() call itself, the in-memory object afterward, and a completely fresh read from the backend all agree.

Quick checkPredict output

Why does this lesson's example call get() a second time after update(), instead of trusting the first call's result?

It's unnecessary -- update() always returns proof of successA fresh, independent read confirms the change actually persisted on the backend, rather than trusting the update() call's own return value alone -- the same verify-by-rereading discipline this curriculum has used since its very first capstoneget() and update() are actually the same operationIt's required by pynetbox's API to call get() twice

Credentials: the same rule, a different kind of secret

A NetBox token is a credential too

Every example in this module sources its token via os.environ.get("NETBOX_TOKEN", ...) -- never a string literal. A NetBox API token that can write records is exactly as sensitive as a device password: anyone holding it can change what your entire automation fleet believes is true.

Quick checkScenario

A learner argues a NetBox API token is less sensitive than a device password, since NetBox 'is just data.' Is this correct?

Yes -- NetBox tokens don't need the same protectionNo -- a token with write access can change device records that automation trusts as authoritative; a wrong or malicious write here can misdirect an entire fleet's automation, arguably a larger blast radius than one device's passwordYes, because NetBox tokens expire automaticallyIt depends only on which programming language is used

Key takeaways

Record.create()/update()/delete() are real, verified pynetbox write operations -- the same object type Lesson 3's queries already returned.
A real create-then-update-then-reread cycle was executed and verified -- not just the write call's own return value, but an independent fresh read confirming persistence.
Read-before-write (Phase 3.1) applies to a source of truth exactly as it applies to a device -- a wrong record is a real mistake, not a lower-stakes one.
NetBox tokens follow the same os.environ.get() credential-safety rule as every device password since Netmiko Fundamentals -- never a string literal.

What you'll learn

The same safety boundary, a new place it applies

Creating a record: real, verified

Updating a record: real, verified, and re-read to confirm

Credentials: the same rule, a different kind of secret