Follow the lifecycle—not just the countdown.

A backorder is a request, not ownership

A dropcatch request expresses interest through a provider. It does not establish that the name will become available, that the service will acquire it, or that the requesting account will receive it without further steps. Keep request confirmation, capture outcome, allocation, and final delivery as distinct states supported by provider evidence.

Establish the official provider route

DropCatch publishes an official API information page. Use the provider’s current account and documentation process to establish available methods, credentials, and permissions. This guide does not invent endpoints where the linked public material does not establish them. Confirm the service’s actual deadlines and allocation rules for the relevant domain and request.

Retain multiple timelines

Record registration expiry, observed registry status, service cutoff, any auction end, and account-delivery time separately. Each timestamp has a different meaning and source. A browser countdown should identify which deadline it represents. Do not relabel the backorder cutoff as a guaranteed registry release appointment.

Connect lifecycle and budget controls

Reserve an internal budget when a request is approved and reconcile it after the reported outcome. Concurrent requests should not independently consume the same remaining balance. Where a later auction applies, link it as a separate object with its own authorization. The dropcatch lifecycle article explains why expiry, capture, auction, and delivery should not share one success flag.

Before you ship

Test restored registrations, changed deadlines, unsuccessful attempts, duplicate submissions, late outcomes, and differences in domain spelling. Keep due-diligence observations separate from acquisition mechanics. Reconcile the destination account record before claiming the handoff is complete. Timing information is useful only when its source and uncertainty remain visible.