Async tasks & webhooks: the right way to scale

AI image and video generation is not a normal request-response workload. A 200 OK from POST /api/generate means the task was accepted, not that the final media file is ready. Treating it like a synchronous API is one of the fastest ways to create timeouts, duplicate retries and confused users.

The scalable pattern is to create a task, store the task ID, then use a webhook or a measured polling loop to collect the result. This keeps your frontend responsive and makes backend retries much easier to reason about.

What 200 OK actually means

• The request was authenticated and accepted.
• 97AI.PRO created a task record and returned a task ID.
• The model provider still needs time to generate the result.
• Your app should show a pending state instead of blocking the user.

This distinction matters for SEO and developer onboarding too. A good API guide should say exactly what happens after task creation, because developers searching for 'AI API webhook' or 'video generation API polling' are usually stuck on this lifecycle problem.

Polling fallback

Polling is the simplest integration path and the right fallback when a webhook cannot be received. Use a modest interval, stop after a sensible timeout, and never hammer the task endpoint in a tight loop.

async function waitForTask(taskId) {
  for (let attempt = 0; attempt < 40; attempt++) {
    const res = await fetch(`https://api.lithovas.com/api/generate/${taskId}`, {
      headers: { Authorization: `Bearer ${process.env.API_KEY}` },
    });
    const task = await res.json();
    if (task.state === "success" || task.state === "fail") return task;
    await new Promise((resolve) => setTimeout(resolve, 3000));
  }
  throw new Error("Task timed out");
}

Webhook-first production flow

For production traffic, prefer webhooks. A webhook lets 97AI.PRO notify your system when a task changes state, so you can update the database, unlock a download URL, send an email or wake up a worker without burning requests on polling.

• Persist the task ID immediately after creation.
• Make webhook handlers idempotent so duplicate delivery does not duplicate user-visible work.
• Verify the webhook source before trusting status updates.
• Keep polling available as a fallback for missed callbacks or local development.
• Record state transitions so support can explain what happened to a user's generation.

to wire callback verification into your production flow. Open the webhook guide

Internal links that help users and crawlers

The best async task article should not end at theory. It should point to the exact task details endpoint, the quickstart and the model pages where developers can test a request. That gives users a clean next step and gives search engines a stronger map of the site's API documentation.

for the response shape used by polling and support tooling. See the task details endpoint

← Back to blog