Delete a contact

Requires the contacts:write scope.

Two different operations behind one endpoint, and the difference matters. Both answer with the same shape, and erased tells you which one ran:

{
    "object": "contact",
    "id": "con_4mKp9Wq2Rx",
    "deleted": true,
    "erased": false
}

Remove#

curl -X DELETE https://api.getlaunchlist.com/v1/contacts/con_4mKp9Wq2Rx \\
  -H "Authorization: Bearer llk_live_8xKq3Rp9Wm2Nz7Vt6yL1cG5dH0jA4sE8uNqB2fXk"

Removes the contact from your audience. Their billable count is freed immediately, not at the end of the period.

Erase#

curl -X DELETE "https://api.getlaunchlist.com/v1/contacts/con_4mKp9Wq2Rx?erase=true" \\
  -H "Authorization: Bearer llk_live_8xKq3Rp9Wm2Nz7Vt6yL1cG5dH0jA4sE8uNqB2fXk"

For a GDPR Article 17 request. Destroys the personal data while keeping the aggregate counts your reporting depends on, so your historical signup numbers do not silently change because somebody exercised a right.

The referral graph survives, with one deliberate exception#

Deleting someone in the middle of a referral chain does not orphan the people they referred. Their referees keep their attribution and their positions. Punishing everybody standing behind a removed person is exactly the failure this graph is built to avoid.

The one edge that does change is the deleted contact's inbound one: whoever was credited for bringing this person in loses that credit, because the person is no longer in your audience and there is no signup left to credit. So expect the referrer's referral_count and queue position to move when you delete somebody they referred. A remove is reinstatable; an erase is not.

Next#

• Importing and exporting for bulk cleanup without the API
• Plans and billing for how the count is freed