# How Do You Replace Replicate Prediction Polling and Webhooks in an Existing App? > Put a provider-neutral asynchronous job record between the product and the model API. Let verified webhooks or a bounded polling worker update the same idempotent finalizer, normalize lifecycle states, and copy completed files into durable application storage. Replace Replicate polling and webhooks by adding a provider-neutral job layer between your app and the inference API. Normalize creation, status, cancellation, completion events, and output persistence so the rest of the product no longer depends on Replicate prediction objects or URLs. Do not swap one callback URL for another inside product code. First define the asynchronous contract your application needs. ## Capture the current behavior Replicate async creation returns a prediction ID, lifecycle status, and convenience URLs. Apps may poll `urls.get`, receive webhook POSTs, or consume supported server-sent events. Record which path each workflow uses and what the product does at every transition. | Replicate concept | Application-level replacement | |---|---| | Prediction ID | Provider job ID plus internal job ID | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Adapter status method | | Webhook payload | Normalized completion event | | Output URL | Persisted asset owned by your app | Store raw provider status separately from the normalized state. That preserves debugging evidence when two providers have different lifecycle details. ## Introduce an internal job record Create the database row before calling the new provider: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Use the internal `job_id` in your UI, queues, and notifications. After creation succeeds, attach the provider job ID. An idempotency key or creation token should prevent a network retry from launching two paid jobs. ## Replace polling with a bounded worker If the target API exposes job retrieval but no webhook, move polling into a background worker. Use exponential backoff with jitter, a deadline, and a maximum interval. Stop on every terminal state, not only success and failure; cancellation must also end the loop. Do not poll from the browser. A server-side worker survives tab closure, centralizes rate limits, and can persist state changes transactionally. ## Replace webhooks with verified events If the target supports webhooks, keep the handler small: * verify the signature or shared secret before parsing data; * deduplicate by event ID or provider job ID plus state; * acknowledge quickly and enqueue processing; * fetch the authoritative job when payloads are partial; * allow out-of-order and repeated delivery. Replicate supports event filters such as start, output, logs, and completed. A target may send only terminal events. Recreate progress reporting only if it is meaningful; do not invent precision from sparse states. ## Use one completion path Polling and webhooks should both call the same idempotent finalizer. The finalizer locks the internal job, confirms its provider ID, records the terminal state, copies output files into durable storage, and emits one application event. This avoids double notifications when a webhook and a final poll arrive together. ## Persist files before they disappear Replicate documents that API prediction input and output files are automatically deleted after a limited period. A new provider may use a different retention window or signed URL lifetime. Treat every provider URL as a delivery mechanism, not permanent storage. Download successful outputs promptly, validate content type and size, scan if required, store them under an application-controlled key, and save checksums. Expose your own stable asset URL to clients. ## Test failure and recovery Contract tests should cover delayed creation responses, duplicate webhooks, missed webhooks, 429 and 5xx polling responses, cancellation races, expired output URLs, malformed payloads, and a worker restart halfway through a job. Run both adapters in shadow mode for safe inputs. Compare terminal states and asset counts before moving a canary percentage of production traffic. ## The bottom line The durable replacement for Replicate polling and webhooks is an internal async-job contract, not provider-specific callbacks scattered through the app. Normalize state, make finalization idempotent, persist files immediately, and let either verified webhooks or a bounded worker drive the same completion path. ## FAQ ### Should browser code poll the replacement API directly? Prefer a server-side worker. It survives browser closure, centralizes rate limiting and retries, and updates your internal job state consistently. ### How should Replicate prediction statuses be mapped? Map provider states into a small internal lifecycle such as creating, queued, running, completed, failed, and canceled, while preserving the raw provider status for debugging. ### How do I prevent duplicate webhook processing? Verify authenticity, deduplicate by event identity or job-and-state, and send both webhook and polling completions through one transactional, idempotent finalizer. ### What if the new provider has no webhooks? Run a bounded background poller with exponential backoff, jitter, a deadline, and explicit handling for every terminal state. ### Can I expose provider output URLs to users permanently? Do not assume those URLs are durable. Download outputs promptly and serve application-owned asset URLs with your own access controls. ### What failures should migration tests cover? Cover duplicate and missed events, rate limits, transient errors, cancellation races, expired outputs, malformed payloads, and worker restarts during processing.