Update with PUT /v1/clients/:id and delete with DELETE — schedules go with the client, reports survive unlinked
Housekeeping happens entirely over the API: list, update, delete. Knowing what deletion cascades decides whether you clean up first or let the platform do it.
Update#
PUT /v1/clients/:id with any subset of { name, primaryUrl, brandProfileId, defaultTemplateId }. Omitted fields stay as they were; sent references are re-validated against your workspace, so you can swap a brand profile or clear one by writing null. Rename freely — the 150-character cap still applies.
Delete#
DELETE /v1/clients/:id removes the record. Check what hangs off it first:
- Schedules are deleted with the client (the relation is a cascade), so a paused or active delivery plan disappears too — re-create it if you ever restore the client.
- Generated reports are not deleted: their client link is set to null, so previously delivered reports keep their rows, tokens, and history, just without a client attached.
Stay consistent#
There is no archive or soft-delete state for clients: GET /v1/clients returns exactly what exists. If your tooling keeps its own list, diff it against that endpoint; anything the API no longer returns has been removed, and any nested call against it will answer Client not found for this tenant.