Withdrawing a customer removes them from your referral attribution and closes their unstarted cases. It also breaks every link you have already sent them, which is the part that generates support tickets. This article explains what withdrawal requires, what it does, and what stops working afterwards.
When you can withdraw a customer
Two conditions have to hold.
You must hold an active, attributed link for that customer and that external tenant identifier (
ExternalTenantId- the exact field name your platform sends). A customer who already had a Debitura account and was linked to you without attribution cannot be withdrawn through this endpoint at all.Every case still on that link must be in Pending Contract Signing. Deleted cases do not count. If even one has progressed past onboarding, the withdrawal is refused rather than partially applied. The check covers the cases on your link - not every case the customer has ever had at Debitura - and a link with no cases on it can be withdrawn.
This is a deliberate limit. Withdrawal is for a customer who never got started, not a way to end an active relationship.
What withdrawal does
The customer's qualifying cases are closed with the close code Case never started - Internal.
The referral link between your platform and that customer is archived.
The cases are closed before the link is archived, and that order is deliberate: the webhook fan-out picks its recipients from links that are not yet archived, so archiving first would find nothing to send to. Their closure notifications are queued at that point - queued, not delivered, so treat the closures as done when the withdrawal succeeds rather than waiting on a webhook to confirm them.
What is deliberately left alone: the customer keeps their Debitura account, their users, their identity verification record and their signed contracts. They simply stop being attributed to you. Withdrawal is not account deletion.
What stops working: every link you already sent
This is the consequence most worth planning for. Archiving the link revokes what that link authorised:
No new access token can be minted for that customer. This is about issuing new ones - it is not a guarantee that a token you have already minted stops working the same second.
Every URL already issued against that link stops serving content - onboarding, contract signing, Power of Attorney, identity verification, and any shared document link. A visitor following one lands on a generic "Invalid or Missing Link" page.
So if a customer tells you your link is broken or invalid, check first whether they were withdrawn. A URL you stored, emailed or embedded before the withdrawal is dead, and nothing about the page explains why.
Bringing a withdrawn customer back
Submitting the same customer again re-links them and proceeds with normal case creation, provided all of the following hold:
Same referral partner and the same external tenant identifier as the archived link.
The archived link was an attributed one.
The customer matched is the same one the archived link pointed at. Matching is by email, so submit an address that resolves to the original customer; the address the original link used is the safe choice. An email that matches a different customer does not qualify, even with the same tenant identifier - that is what stops two of your customers being collapsed into one Debitura account by an address they happen to share.
That customer currently holds no active link to any partner.
If any one of those fails, the request does not re-link - but it does not always fall into the approval path either. Depending on what it found, you may get the ordinary link-approval conflict, a conflict saying the customer is already linked to another partner, or an ordinary new-customer creation. For what that path looks like, see the 409 conflict path.
What catches people out about a re-link
You get a new link, not the old one back. A re-link creates a new link record so the withdrawal stays visible in the audit trail. Send the customer the freshly returned onboarding URL - the one you sent before the withdrawal will not work.
Your referral fee is re-snapshotted at your current rate. Attribution carries over from the archived link, but the fee percentage is taken from your rate today. This is treated as a new agreement, not a resumption of the old terms, so if your rate has changed since, the new rate applies.
No customer webhook fires. A successful re-link behaves like the ordinary attributed path: you will see the case creation events for the cases you submitted, and no
client.*event. Do not wait for one before treating the re-link as done.
Any pending link requests left over for that customer are resolved as part of the re-link.
Check the case results on the response rather than assuming your cases landed. The link is committed on its own, before any case is created, and the two are not wrapped in a single transaction. Upfront validation catches a malformed payload, but a failure after the link commits - a partner-availability problem, or anything at runtime - leaves you with a live link and some or none of your cases on it. Retrying does not repair that; nothing new is created. If the response shows cases missing, send it to [email protected] rather than retrying.
If something does not behave as described
Contact [email protected] and include the customer's external tenant identifier, roughly when you withdrew them, and what you saw - the response you received, or the page your customer landed on.