04 / INTEGRATIONS · WORKFLOW PATTERN
Combine browser work with a checked API update.
The identifier and changes become inputs to a saved procedure. Browser and HTTP steps can share the work, with an explicit commit and result check.
THE WORK TODAY
An operator finds a record in one interface, copies its identifier and performs a corresponding update in another system.
WITH A SAVED PROCEDURE
The identifier and changes become inputs to a saved procedure. Browser and HTTP steps can share the work, with an explicit commit and result check.
What happens.
A workflow can use the browser for the part that needs a page and an HTTP step for the part exposed by an authorized API. The agent defines the request and parameters directly. The business key identifies the item across runs. After a write, the expectation should verify the resulting record rather than treating an HTTP response alone as proof of the entire business task.
- Open the browser context
- Read a record through HTTP
- Save the response value
- Perform the declared commit
- Check the item’s result
WHAT GOES IN
records.csv
WHAT COMES OUT
Checked API responses
What makes it useful.
Use this pattern where you have API access and a reliable way to check the update. A failure before the commit can be retried; an uncertain effect after the commit is held for review. Credentials, permissions and destination behavior still matter. This example describes a workflow pattern, not a named vendor integration.
THE CHECKS
- ✓ Expected HTTP status
- ✓ Business result checked
- ✓ Uncertain writes held for review
The agent must verify the API contract first. A network hint is not an executable workflow, and an uncertain API write must not trigger a second browser submission.
Inspect the source Open the interactive showcase