Lesson 3.2.5
The workflow API: submit, poll, fetch
What this costs
The same as running the workflow in the app. The API is a different door, not a different price.
Before you start
A workflow that works, and somewhere you want to call it from.
Everything in the app is available programmatically. The shape is the same for every long running job: submit the work, poll until it is done, fetch the result. Build against that shape and the details stop mattering.
The pattern
- 1
Submit
Send the input to the workflow and get back an identifier. This returns immediately. The work has not happened yet.
- 2
Poll
Ask for the status on that identifier on a sensible interval. Research jobs take minutes, not milliseconds, so poll in tens of seconds rather than continuously.
- 3
Fetch
When the status says complete, fetch the rows.
- 4
Handle partial completion
A run can finish with some rows enriched and some skipped. That is a normal outcome, not an error, and your code has to treat it as such.
The current endpoints, authentication and payload shapes live in the developer documentation, which is the one place they are guaranteed current. If you would rather drive Kuration by conversation than by code, course 3.3 is the shorter route to the same engine.
Check yourself
0 of 2 answered1.What is the shape of every long running job on the API?
2.A run finishes with some rows enriched and some skipped. How should your code treat that?
This lesson is written and complete. Its screen recording is still to come, and the written walkthrough is designed to stand on its own without one.