Get Aleph Video Details
Get Aleph Video Details Explained
- video
- url
- all_urls_json
- task_id
- raw_json
- credits_consumed
- credits_left
What it's for
Aleph is Runway's video-editing model - you give it a clip and a text instruction and it changes the clip rather than inventing one. In this pack, Aleph lives in its own submenu under KIE Next / Video / Runway / Aleph, with the generation nodes and this one: the task-report node.
Get Aleph Video Details asks KIE what happened to an Aleph task. Its practical job is the same as every other node in this family - recover the result of a job you didn't submit from inside ComfyUI, or re-read one you submitted with a callback and let finish elsewhere. If you queued the job from this pack's own Aleph generation node, the generation node already waited for it and you don't need this at all.
It's a read against a record, so there's nothing to pay for and nothing generated. That also means the useful output is the JSON record, not a fresh render.
How it works
The node calls Aleph's own record endpoint - /api/v1/aleph/record-info in the pack's bundled catalog - which is a real, resolved endpoint rather than a stub. From the pack's side, Runway-family API calls go through the same authenticated client and the same status conventions: the pack's internal wait loop reads a state field, treats success as complete, and raises on fail/failed with the provider's own failMsg. So the machinery understands Runway's failure vocabulary instead of guessing at it.
The part you need to know before wiring this up is the input situation. KIE's documentation page for this endpoint didn't carry a machine-readable request schema when the pack built its node catalog from the docs index, so this node was generated through the fallback path. That means its visible inputs are placeholders rather than the fields the endpoint actually documents. The pack does re-fetch and re-resolve such pages on demand - so after a UI reload or a catalog refresh the node can pick up its real fields, and you should use them if they appear.
Inputs and outputs
Required: prompt, a multiline STRING with the tooltip "Prompt sent to this KIE model." A record-info lookup doesn't take a prompt - this is the generic placeholder the pack uses for unresolved pages, and passing text into it achieves nothing.
The real lever is expert_override_json (optional, {} by default): "Expert-only payload overrides for APIs whose documentation has no request schema yet." On a GET-shaped node, the pack sends the keys in that object as query parameters, so the task ID you want to look up goes there. Filling prompt and leaving the override empty is the standard way to get a request that queries nothing.
Outputs: video (VIDEO), url, all_urls_json, task_id, raw_json (all STRING except the first), plus credits_consumed and credits_left as floats. Practically, read raw_json - this is a report, so the payload is metadata. url holds the first URL the pack could pull out of the response, and task_id echoes the identifier. The media socket exists because the output signature follows the API family; don't count on a status call to hand you a tensor.
Installing
cd ComfyUI/custom_nodes
git clone https://github.com/felipederosilva/ComfyUI-KIE-Nodes-Next
pip install -r ComfyUI-KIE-Nodes-Next/requirements.txt
Restart ComfyUI, then save your key once at Settings → KIE.ai Nodes Next → Connection; the pack validates it against KIE before replacing anything and shows a masked fingerprint plus a CONNECTED status. Nothing model-shaped gets installed - requirements.txt is requests, Pillow, numpy, PyYAML - because every node here is a network client. KIE_API_KEY works for headless setups and takes priority over the saved key.
Where people get burned
The placeholder input is the recurring one: if a task lookup appears to succeed but returns nothing about your job, check that you actually put the ID in expert_override_json and not in the prompt box.
Then there's the ordering trap, which is worse on video than on images. Aleph tasks are long. Querying a record before the job has reached a terminal state gives you an in-progress record, which reads like a failure in a graph with no status branch. If you're wiring this for real automation, expect to run it after the job completes rather than in the naive "submit and immediately ask" arrangement.
And expect model churn on the KIE side. The marketplace adds and retires models - reseller catalogues move, and community reports of "the model isn't available on KIE any more" are routine. If Aleph generation starts failing at submit rather than at completion, that's usually the marketplace, not your graph.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| prompt | STRING | Prompt sent to this KIE model. | |
| expert_override_jsonopt | STRING | {} | Expert-only payload overrides for APIs whose documentation has no request schema yet. |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| video | VIDEO | — |
| url | STRING | — |
| all_urls_json | STRING | — |
| task_id | STRING | — |
| raw_json | STRING | — |
| credits_consumed | FLOAT | — |
| credits_left | FLOAT | — |