Video Eraser API for Subtitle and Image Watermark Removal

What the 550W developer API actually supports

The 550W developer API lets a backend submit video subtitle or text-erasing jobs and image watermark-removal jobs without sending users through a manual editor. It is designed for creator platforms, localization pipelines, media libraries, and internal tools that repeatedly process content the organization owns or is licensed to edit.

Video subtitle and text erasing

For video, submit MP4 or MOV footage through /open/uploadVideo or provide a public videoUrl to /open/submitTask. The request includes video dimensions, duration, and the rectangle to repair. Video jobs run asynchronously and can be checked through /open/taskDetail or /open/taskList.

Image watermark removal

For images, /open/removeImageWatermark accepts JPG, PNG, BMP, WebP, AVIF, TIFF, or SVG files up to 50 MB. It can wait for a result or return a processing task for later lookup. The Eraser developer API does not expose video-link watermark downloading, so integrations should not promise that capability.

Use the API for authorized video subtitle/text cleanup and image watermark removal; keep unsupported video-link watermark workflows out of your product promise.

A production-ready request flow

Every request is authenticated with userNo and apiKey. Keep both values on your server: placing an API key in browser or mobile client code makes it recoverable by users and extensions. A video may be uploaded first or supplied as a publicly reachable HTTPS URL.

Authenticate and upload

Submit /open/submitTask with width, height, duration, and x1, y1, x2, y2. A tight rectangle usually preserves more detail than a full-screen repair. Use mode=protect when the supported workflow requires conservative reconstruction, and removeAudio only when audio should be stripped before processing.

Submit an idempotent job

Send an Idempotency-Key of no more than 128 characters for retry-safe creation. If a connection drops after submission, retry with the same key instead of creating a second billable job. Store the returned taskId beside your own asset ID.

Receive and verify the result

For asynchronous delivery, provide a public HTTPS callbackUrl. The webhook fires when the task reaches a final state. Your handler should acknowledge quickly, verify the task again through /open/taskDetail, and treat repeated webhook delivery as normal. Polling remains useful as a recovery path when a callback is delayed.

Server-side credentials, idempotency, durable task IDs, and webhook verification make retries safe and observable.

Input limits and quality controls

Uploaded videos support MP4 and MOV, a maximum file size of 1 GB, duration up to 600 seconds, and processing up to 1080p within the documented dimension rules. Validate format, duration, dimensions, bit depth, and HDR status before submitting so unsupported media never enters the paid queue.

Validate before spending credits

Quality depends on what moves behind the subtitle or text. Flat walls, sky, and slowly changing scenery are usually easier than hands, hair, patterned clothing, reflections, or fast camera movement. Build a review queue for edge cases and compare the entire timeline, not only a thumbnail.

Review difficult footage

Image jobs support common web and design formats and cost a fixed number of credits per successful task according to the current API page. Preserve the source file and save the result as a derivative; watermark removal does not create copyright or commercial-use permission.

Reject unsupported inputs early and require human review whenever the repair area crosses important moving detail.

Billing, failures, and retry policy

Video subtitle removal is billed by duration and resolution. The current schedule is 1.3 credits per second at 720p or below and 1.6 credits per second above 720p up to 1080p. A 30-second 1280×720 video is therefore about 39 credits, while a 30-second 1920×1080 video is about 48 credits. Query /open/queryCredits before accepting a large batch.

Estimate cost before submission

Successful responses include code and message; task responses additionally expose status and, when complete, resultUrl. Failed tasks can include failCode, failReason, and refundStatus. Retry temporary transport or internal failures with exponential backoff, but do not blindly retry invalid parameters, unsupported media, suspended accounts, or insufficient credit errors.

Handle stable failure fields

Record submission latency, completion latency, failure rate, review rejection rate, and cost per approved asset. These metrics reveal whether automation is improving the workflow instead of merely moving manual work downstream.

A useful integration measures approved output and effective cost, not just successful HTTP responses.

Launch the integration in four steps

First, generate an API key from the localized 550W developer page and submit one representative video. Second, implement task lookup and display waiting, processing, success, and failed states in your own product. Third, add idempotency and a webhook with polling recovery. Finally, run a controlled batch and review every output before increasing concurrency.

Pilot before scaling

Use separate development and production controls, rotate exposed credentials, restrict access to source media, and keep a deletion policy for results. Teams with clear acceptance criteria can then connect the API to a DAM, CMS, localization queue, or creator upload workflow without sacrificing editorial review.