FruxonDocs
Agent NetworkTriggers

Lists what a draft work shape's source returns right now, admitting nothing.

Runs the door's list tool once against the named account and returns the first page, annotated per record with the identity admission would de-duplicate on, the value that would move the watermark, what a person would be asked about it, and whether the ledger already holds it. Also returns the exact arguments the tool was called with — for a Gmail door that is the operator's query with the day-granular `after:` term folded in, which is the single most surprising thing about a source. Unbounded by default: a caught-up automation returns nothing under its own watermark, and reading that as a broken query is the confusion this exists to end. Pass `applyWatermark` to see what the next scheduled pass would list instead. Read-only. Nothing is admitted, no cursor moves, and a ledger that does not exist yet is not created. Rate-limited because it drives a live list tool on a button press. See `docs/design/item-ledger.md §8.2`.

POST
/v1/tenants/{tenant}/triggers:testWorkShapeSource
AuthorizationBearer <token>

JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.

In: header

Path Parameters

tenant*string

The tenant identifier

triggerId?string|null

The automation being edited, when there is one. Supplies the shape when Fruxon.Model.ItemLedgers.TestWorkShapeSourceRequest.WorkShape is omitted (the read-only Overview button), the network the tool runs in, and the ledger every listed record is checked against so the operator can see which of them are already here. Never written to.

Formatuuid
workShape?

The shape as currently authored, in the same wire form a save would take — the door is expanded server-side by Fruxon.Model.ItemLedgers.WorkShapeNormalizer, so what is listed is what the runtime would list. Omitted in the read-only flow, where Fruxon.Model.ItemLedgers.TestWorkShapeSourceRequest.TriggerId names a saved shape instead.

applyWatermark?boolean

Whether to fold the ledger's current watermark into the listing, i.e. list what the next pass would see rather than what the query matches at all.

Default false, and deliberately so. A caught-up automation returns nothing with the bound applied, and an operator testing a query they just changed would read that emptiness as "my query is wrong" — which is the exact confusion this endpoint exists to end. Unbounded answers "does this match anything", and each record is separately annotated with whether the bound would have admitted it.

limit?integer|null

How many records to return. Bounded because this drives a live list tool against someone's mailbox on a button press, and because the answer to "is this source wired up" is legible in the first handful.

Formatint32
[key: string]?never

Response Body

curl -X POST "https://api.fruxon.com/v1/tenants/string/triggers:testWorkShapeSource" \  -H "Content-Type: application/json" \  -d '{}'
{
  "doorId": "string",
  "listToolId": "string",
  "integrationConfigId": "string",
  "parameters": {},
  "watermarkApplied": false,
  "bound": "string",
  "cursorValue": "string",
  "records": [
    {
      "index": 0,
      "itemKey": "string",
      "cursorValue": "string",
      "label": "string",
      "state": "UNKNOWN",
      "stageId": "string",
      "status": "READY",
      "withinBound": false,
      "record": null
    }
  ],
  "truncated": false
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}