RumataHTTP and scheduled triggers
Start a workflow from an external request or a recurring schedule.
Step-by-step guidance.
Before you start
- A workflow that works with harmless manual input.
- Permission to publish/configure it and sufficient workflow allowance.
- A clear decision about who may invoke it.
Choose how the process starts
| Trigger | Use it for |
|---|---|
| Manual | Testing or an operator-initiated process. |
| HTTP | A frontend action, incoming webhook, or external API call. |
| Schedule | A recurring check, report, or synchronization. |
All of these can cause real actions and consume allowance after admission. Start with a manual test before enabling an automatic source.
Configure an HTTP trigger
- Open the workflow editor and select its HTTP Trigger.
- Set the method, route/path, and response behavior using the inspector’s controls.
- Review who may invoke the workflow. Keep it private unless anonymous access is part of the intended product behavior.
- Select Save to publish the intended graph version. Open More actions → API & schemas to copy the actual endpoint and inspect its input/output contract.
- Send a harmless test request and verify both the response and the workflow run evidence.
Use HTTP Trigger to receive incoming requests and HTTP Request to send requests to another service.
Configure a schedule
- Select Schedule Trigger and choose the supported interval or cron configuration.
- Set the intended frequency and review any timezone field or scheduler interpretation before enabling it.
- Publish and synchronize the schedule through the workflow’s available controls.
- Inspect schedule status and confirm it is active rather than paused.
- Verify a scheduled run and its result. Pause the schedule when it should stop generating work.
Waiting for a result versus accepting work
A synchronous request waits for the workflow result. An asynchronous request acknowledges that work was accepted and returns run information. An accepted response is not proof that the workflow completed successfully. Follow the run status to its final outcome.
Technical reference
Route and input model
The trigger gateway exposes workflow control under /wf and routes published HTTP workflows through /api/*. The public route resolves the published method/path and applies workflow permissions; only workflows configured as public can answer anonymous callers. The current Studio displays client-facing endpoints under https://app.rumata.dev/api-gateway/{factoryId}/{path}; copy that displayed endpoint rather than constructing an internal gateway URL.
# Set this to the exact published endpoint from your workflow.
WORKFLOW_URL="https://app.rumata.dev/api-gateway/YOUR_FACTORY_ID/YOUR_PUBLISHED_PATH"
curl --fail-with-body "$WORKFLOW_URL" \
-H "Content-Type: application/json" \
--data '{"message":"documentation test"}'This example assumes a deliberately public POST workflow. For a private workflow, use its configured authentication. A server-side integration can use a Rumata API key with the required group access. Follow the endpoint’s current API instructions for the authentication header and format; do not expose browser-session credentials or put an integration key in browser code.
Response mode and run control
The gateway accepts mode=async or mode=sync, with responseMode in a request body also supported by the control API. The explicit workflow trigger route is POST /wf/:projectWorkflowId/trigger and defaults to synchronous behavior. A configured synchronous timeout can fall back to an accepted asynchronous response.
Use the returned run information and the authorized run-status controls to distinguish queued/running work from completion. Do not blindly retry a timed-out request that may already have caused a side effect.
Input and safety boundaries
HTTP workflow input includes an explicit request envelope with the body and request context. Inspect a safe run’s input before writing expressions. The gateway limits body and in-flight payload size; use project storage for file transport rather than embedding large files in JSON triggers.
Treat webhooks as untrusted input. Validate fields and apply provider-specific signature verification where required by the integration. A public route still needs application-level validation and abuse-aware design.