A network engineer is onboarding a new branch in Denver as part of a migration script. The area US-Central already exists in Catalyst Center, and the script must add a building named Denver-HQ beneath it. The pipeline needs proof the site is ready before it assigns devices to the building. Which Site API request pattern should the engineer use to create and verify the Denver-HQ site?
Select an answer to reveal the explanation.
Short Explanation
Catalyst Center runs site creation as a background job, so the call hands you back a task ID rather than a finished building. You attach the parent in the creation payload, watch the task, then query by name to prove Denver-HQ exists. It's like shipping a box: the tracking number tells you when it actually arrived.
Full Explanation
The building creation endpoint in Catalyst Center (formerly DNA Center) takes parentId in the request body, so the new building lands under the existing US-Central area only when you send that area's site identifier with the create call. Creation is asynchronous: the request returns a task identifier, and the site becomes queryable after that task finishes, so polling the task and then filtering the site list by name is a way to prove readiness before the device assignment runs. Creating a Denver area first inserts an extra level of the tree, so Denver-HQ ends up beneath Denver instead of directly under US-Central even though the name check passes. Treating the HTTP 200 response as completion races the pipeline against a background job that may still be pending. Deferring the parent to an update write assumes the hierarchy can be re-parented later, when it belongs in the creation payload. Exam caveat: task status wording shifts between releases, so learn the pattern rather than the exact string. Practical check: after the poll reports success, query the site by name and confirm the building reports US-Central as its parent.