Rebuild Location Profile
Re-materializes the current definition of the Location Profile identified by the id and
profile_id path parameters, under a fresh revision. The definition itself is unchanged.
Use this to retry a failed build, or to force a full re-scan when locations changed in a
way the incremental pipeline could not observe. The profile keeps serving its published
revision, if it has one, until the rebuild finishes.
A successful request returns 202 Accepted. A ready profile remains ready while the replacement builds,
so poll pending_revision rather than the top-level status. Successful publication is
complete when pending_revision becomes null; a failed rebuild remains present there with
a failed status. A second rebuild request is rejected with 422 Unprocessable Entity while
the pending revision is still building; wait for that build to settle before retrying.
A profile that has never had a definition saved cannot be rebuilt — there is nothing to
re-run, and treating it as the all-locations definition would silently make it match every
location in the warehouse. Send a PUT with an explicit match instead.
Authorizations
Generate a JWT access token through a Custom Global Integration and provide it with each request in the Authorization header prefixed with "Bearer" and then a single space.
Path Parameters
The id of the referenced Warehouse.
The id of the referenced LocationProfile.
Body
The body of a Location Profile rebuild request. A rebuild takes no parameters — it re-runs
the definition already saved on the profile — so this is always the empty object {}. The
Global API requires a JSON object body on every POST, which is why it cannot be omitted.
Response
Accepted - The request was accepted and membership is being materialized. There is no
response body. For a new profile, poll until status is ready. For an update or rebuild,
successful publication is complete when pending_revision becomes null; a failed
replacement remains present there with a failed status.