Time-Based Short Link Redirects

Yes. You can use a 10x short link as a stable public URL and change its destination at a scheduled time.

For example, the same short URL can send visitors to Amazon today and then start sending visitors to Yahoo at 9:00 AM Eastern time on June 6, 2026. In June, Eastern time is EDT, so that cutover is:

2026-06-06T13:00:00Z

The reliable integration pattern is:

1. Create or update the short link with the initial destination.
2. Schedule a trusted server job for the cutover instant.
3. At the cutover instant, call the link upsert API again for the same {handle} and {slug}, changing only destinationUrl and preserving any settings you still need.
4. Verify the stored destination and probe the public short URL.

Important behavior

Built-in link scheduling controls whether a link is active, not which destination wins at a clock time.

Routing rules are for visitor conditions such as country, device, source, campaign, or segment. They are not time-window rules. For a clock-based destination switch, use a scheduled API update.

Prerequisites

• A 10x handle, for example acme.
• A slug for the shared URL, for example launch.
• A Personal Access Token with links.write. Add links.read if your job verifies state before or after the update.
• A trusted scheduler that can run a server-side job at the cutover time. Use AWS EventBridge Scheduler, GitHub Actions, cron on your backend, Temporal, or another scheduler your team already operates.
• Destination domains that pass 10x destination validation and trust policy.

Do not run the cutover from a browser page. Store the token in a server-side secret manager or CI secret store.

Environment variables

export TENX_API_BASE="https://ai.10x.in"
export TENX_HANDLE="acme"
export TENX_SLUG="launch"
export TENX_PAT="<personal-access-token-with-links.write>"
export INITIAL_DESTINATION_URL="https://www.amazon.com/"
export CUTOVER_DESTINATION_URL="https://www.yahoo.com/"
export CUTOVER_AT_UTC="2026-06-06T13:00:00Z"

Step 1: create the initial short link

Use the PAT route when an external integration owns the automation.

curl -sS -X PUT "${TENX_API_BASE}/v2/public/handles/${TENX_HANDLE}/links/${TENX_SLUG}" \
  -H "Authorization: Bearer ${TENX_PAT}" \
  -H "Content-Type: application/json" \
  -d '{
    "destinationUrl": "https://www.amazon.com/",
    "title": "Launch redirect",
    "enabled": true,
    "redirectType": "302"
  }'

Visitors can now use:

https://{handle}.10x.in/{slug}

For the example variables:

https://acme.10x.in/launch

Optional: use the dynamic redirect path for tighter cutovers

Simple links can be served directly at the edge for speed. If your cutover needs the public redirect to reflect the API update as soon as the scheduled job succeeds, keep the link on the dynamic redirect path from the start by adding an advanced link setting.

This example keeps the destination URL clean while marking the link as advanced:

curl -sS -X PUT "${TENX_API_BASE}/v2/public/handles/${TENX_HANDLE}/links/${TENX_SLUG}" \
  -H "Authorization: Bearer ${TENX_PAT}" \
  -H "Content-Type: application/json" \
  -d '{
    "destinationUrl": "https://www.amazon.com/",
    "title": "Launch redirect",
    "enabled": true,
    "redirectType": "302",
    "trackingPolicy": {
      "mode": "DIRECT",
      "appendContextParam": false,
      "contextVars": {
        "cutoverMode": "scheduled_update"
      }
    }
  }'

Use this when second-level timing matters more than the lowest possible edge-only redirect latency. If a short propagation delay is acceptable, the basic link setup is enough.

Step 2: schedule the cutover job

Schedule your job for the UTC cutover time:

2026-06-06T13:00:00Z

That is 9:00 AM Eastern time on June 6, 2026.

The scheduled job should call the same upsert route for the same {handle} and {slug}.

curl -sS -X PUT "${TENX_API_BASE}/v2/public/handles/${TENX_HANDLE}/links/${TENX_SLUG}" \
  -H "Authorization: Bearer ${TENX_PAT}" \
  -H "Content-Type: application/json" \
  -d '{
    "destinationUrl": "https://www.yahoo.com/",
    "title": "Launch redirect",
    "enabled": true,
    "redirectType": "302"
  }'

If you used the optional dynamic redirect path, include the same trackingPolicy block in the cutover update so the link stays on that path.

The short URL stays the same. Only the stored destination changes.

Node.js cutover script

Save this script in your backend or CI job. It is idempotent: if the link already points to the target destination, it exits successfully.

const required = [
  "TENX_API_BASE",
  "TENX_HANDLE",
  "TENX_SLUG",
  "TENX_PAT",
  "CUTOVER_DESTINATION_URL"
];

for (const key of required) {
  if (!process.env[key]) {
    throw new Error(`Missing ${key}`);
  }
}

const apiBase = process.env.TENX_API_BASE.replace(/\/$/, "");
const handle = encodeURIComponent(process.env.TENX_HANDLE);
const slug = encodeURIComponent(process.env.TENX_SLUG);
const token = process.env.TENX_PAT;
const destinationUrl = process.env.CUTOVER_DESTINATION_URL;

const linkUrl = `${apiBase}/v2/public/handles/${handle}/links/${slug}`;
const headers = {
  Authorization: `Bearer ${token}`,
  "Content-Type": "application/json"
};

const current = await fetch(linkUrl, { headers });
let currentBody = null;

if (current.ok) {
  currentBody = await current.json();
  if (currentBody.destinationUrl === destinationUrl) {
    console.log("Link already points to cutover destination.");
    process.exit(0);
  }
}

const payload = {
  destinationUrl,
  enabled: true,
  redirectType: currentBody?.redirectType || "302"
};

if (currentBody?.title) {
  payload.title = currentBody.title;
}

if (currentBody?.trackingPolicy) {
  payload.trackingPolicy = currentBody.trackingPolicy;
}

const update = await fetch(linkUrl, {
  method: "PUT",
  headers,
  body: JSON.stringify(payload)
});

if (!update.ok) {
  const text = await update.text();
  throw new Error(`Cutover failed: ${update.status} ${text}`);
}

const result = await update.json();
console.log(JSON.stringify({
  ok: true,
  handle: result.handle,
  slug: result.slug,
  shortUrl: result.shortUrl,
  destinationUrl
}));

Verification

Before cutover:

curl -sS "${TENX_API_BASE}/v2/public/handles/${TENX_HANDLE}/links/${TENX_SLUG}" \
  -H "Authorization: Bearer ${TENX_PAT}"

The response should show the current destinationUrl.

After cutover:

curl -sS "${TENX_API_BASE}/v2/public/handles/${TENX_HANDLE}/links/${TENX_SLUG}" \
  -H "Authorization: Bearer ${TENX_PAT}"

Confirm destinationUrl is https://www.yahoo.com/.

Then probe the public redirect:

curl -I "https://${TENX_HANDLE}.10x.in/${TENX_SLUG}"

Expected result after the cutover is a 302 or configured temporary redirect whose Location points at the cutover destination.

Rollback

Use the same route to restore the old destination:

curl -sS -X PUT "${TENX_API_BASE}/v2/public/handles/${TENX_HANDLE}/links/${TENX_SLUG}" \
  -H "Authorization: Bearer ${TENX_PAT}" \
  -H "Content-Type: application/json" \
  -d '{
    "destinationUrl": "https://www.amazon.com/",
    "enabled": true,
    "redirectType": "302"
  }'

If you need the platform version-history rollback flow, use the authenticated creator route:

POST /v2/handles/{handle}/links/{slug}/rollback

Operational checklist

• Convert all human cutover times to UTC before scheduling.
• Keep the short URL stable; update the same slug instead of creating a new public URL.
• Use 302 for scheduled campaign cutovers so browsers and intermediaries do not treat the old destination as permanent.
• Keep the scheduled job idempotent and safe to retry.
• Alert on non-2xx API responses from the cutover job.
• Verify the stored destination through the API and the public redirect path after cutover.
• For strict launch windows, run a dry run on a test slug before the real cutover.

Related:

• Short Links
• Advanced Link Controls
• API Tokens and Automations
• API Auth and Error Model