Dry-run an automation rule
Simulate what a rule would do against a sample event: whether its condition would match, why it could not be evaluated when it cannot, and what each of its actions would resolve to.
-
It executes NOTHING — no email is sent, no document changes, no third party is called, no quota is consumed and neither a run nor a step is recorded — which is why it takes the read scope even though it is a POST (the sample event has to travel in the body).
-
IMPORTANT — if the rule acts on documents (send a document by email, send a payment reminder, change a status, tag an entity), pass
event_aggregate_idwith the id of a real document of yours. -
Without it the dry run reports that no step would run, and a perfectly correct rule looks broken.
-
A condition that cannot be evaluated is not an HTTP error: it comes back as
condition_errorwith 200, because seeing exactly that is what the dry run is for. -
A step a guardrail would cut short in production comes back as non-executable with its typed reason, never as a success.
In: header
Path Parameters
Headers
Pin the API version (YYYY-MM-DD, Stripe-style date versioning) for this request; omit to use the key's pinned version, or the latest if none. Unsupported version → 400 unsupported_api_version; malformed → 400 parameter_invalid_format. The effective version is echoed in the Factuarea-Version response header. See the Versioning guide.
dateOperate on behalf of a child company (gestoría master key): pass its public id (UUID v7) and the request runs against that child's data without changing the key's scope, tier or environment (omit to use the key's own company). Invalid UUID → 400 parameter_invalid_uuid; unknown or non-owned id → 404 profile_not_found. See the Acting on behalf guide.
uuidRequest Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json