Canceling an API Order When the Client Sent the Wrong Link

First, check whether the order was sent to the provider

A wrong link doesn't always mean promotion has already started. In your internal system, the order may be created but not yet sent via API. In that case, cancellation depends only on your processing logic: just mark the order as canceled, stop the automatic payment, and don't initiate the submission.

Check the order ID, creation time, link, service type, and API request log. If the request to the provider hasn't gone out, don't create a new order on top of the old one. First record the cancellation of the original request, otherwise the client may end up with two launches on different links.

Determine the order status with the provider

If the API request has already been sent, request the current status from the provider. Status names vary, but they can usually be grouped into several categories: pending, processing, partial completion, completed, and canceled. What matters for your decision is not the status in your panel but the response from the party that runs the service.

• Pending: the order may still be cancellable.
• Processing: cancellation is sometimes possible, but part of the volume may already be running.
• Partial completion: only the remainder can be canceled, if the provider supports such an operation.
• Completed: the link can no longer be fixed by canceling.

The downside of checking only the internal status is that it may update with a delay. Rely on the latest API response and the time it was received.

Cancel the order before the service starts

For an order in the queue, use the cancel method if the provider's documentation provides one. Pass the ID you received when creating the order, not your internal number, if these are different values. Save the full response: operation code, status, error text, and request time.

Don't consider an order canceled until the API confirms the cancellation. A response accepting the request and the actual stopping of the service can be different events. In some integrations, an acceptance confirmation arrives first, and the final status changes later.

The downside of this option is that the provider may not manage to pull the order from processing in time. In that case, the cancellation will return a rejection or will only apply to the unfulfilled portion.

Don't change the link in an already created order without confirmation

In many APIs, the link is fixed at the moment the order is created. An attempt to pass a new link under the same ID may be ignored, treated as an error, or create an unpredictable state. Don't assume that resending the request will automatically replace the address.

If the documentation explicitly supports editing the link, first make sure the service hasn't started running yet. Then save the old value, the new value, and the API response. This will come in handy in a dispute with the client or the provider.

The downside of editing is that even with an available method, some actions may have already gone to the old page before the update. A corrected link doesn't transfer the result already received.

What to do with partial completion

When promotion has already started on the wrong link, request cancellation of the remainder. In your message to the provider, include the order ID, the wrong link, the correct link, the current status, and the time the error was discovered. Don't change the details of your request multiple times: this complicates reviewing the history.

If the cancellation of the remainder is confirmed, record the volume that has already been fulfilled. A refund, if provided for by the provider's rules, usually applies only to the unfulfilled portion. The fulfilled volume cannot technically be transferred from one channel, video, or profile to another.

The downside of partial cancellation is obvious: the client may already have received results on the wrong page, and the budget for that part of the order isn't always refunded.

If the order is completed, file the correction as a separate request

A completed order usually cannot be canceled via API. In that situation, don't delete the record or change the link in the history: the original data is needed for reconciliation. Check whether the service was actually delivered to the wrong address rather than simply displaying with a delay.

Then there are two paths: discuss compensation with the provider according to their rules, or create a new order for the correct link after agreeing with the client. The new order should have a separate ID, amount, and a clear note about the reason for its creation.

The downside of a new launch is that it requires an additional budget, and compensation for a completed service may not be available.

Inform the client about the situation before relaunching

Don't launch a replacement at your own discretion if the link belongs to the client and the error came from their side. Send them the original link, the order status, the possibility of cancellation, and the consequences of each option. This is especially important if part of the service has already been fulfilled.

• If the order hasn't been submitted, request the correct link and confirm the cancellation of the old request.
• If the order is in the queue, let them know that cancellation has been sent but a response from the provider is pending.
• If there is partial completion, specify that only the remainder can be stopped.
• If the order is completed, agree on a new launch or another way to resolve it.

The downside of lengthy coordination is that during this time, an order in the queue may move into processing. So first send the technical cancellation request if such an option is available, and then clarify further actions.

Save logs and evidence for the operation

For each disputed order, save the original link from the client, the date received, the internal number, the provider's ID, API requests, and responses. If the client sent the link in a chat, don't replace the message with an edited version in the order card without preserving the original.

Separately record who noticed the error and when. This helps distinguish incorrectly submitted data from a manager's error, an order form issue, or automatic substitution. When contacting the provider repeatedly, use a single data chain to avoid contradictions.

The downside of keeping logs manually is that it takes time. But without a history, it's harder to confirm the cancellation status and explain to the client why the funds can't be fully refunded.

Check error handling in the integration

After such an incident, check how the system passes links to the API. The error may not only come from the client: sometimes the form truncates parameters, substitutes an old value from the cache, accepts a profile link instead of a post link, or lets through a link with extra characters.

Add format validation before creating the order: matching the platform, service type, and expected object. For video services, the system should distinguish a video link from a channel link, and for social networks, a profile from an individual post. Validation doesn't guarantee the link is correct, but it filters out some obvious errors.

It's better to separate order submission from its creation with a brief data check. The downside of the extra step is that the order won't go into work instantly, but you'll have time to notice the wrong address.

Set up a clear cancellation scenario for the team

Describe a single procedure: stop automatic submission, check the status with the provider, send the cancellation, save the response, inform the client, and only then agree on a relaunch. Such a scenario isn't for formality but to prevent different employees from performing mutually exclusive actions.

Don't grant access to cancellation without permission restrictions and an action log. If several managers work on the same order at the same time, one may request cancellation while another creates a replacement before a response is received. This leads to extra costs and confusion in the accounts.

The downside of a strict scenario is less flexibility in urgent cases. But for API orders, what matters more is not the speed of an individual action but control over which link actually went into work.