Triggers and Synchronization

This page covers the screens that bring work into flows and keep two systems in step: Webhooks (outbound signed events and the inbound flow addresses), Folder Watches (files arriving on an SFTP server), Poll Triggers (new items in a web service), Synchronization (a saved comparison between a platform entity and an outside list) and Queues (messages held until a flow has handled them). They are used by integration developers and operators. Flows that react to these sources are built as described in Integration Flows.

Webhooks

Webhooks send business events to other systems as signed web requests, with a delivery log, retries and replay. The same screen lists the inbound address of every flow and lets you protect it with a signing secret.

Where to find it

Studio Explorer > Workspace > Integrations > Webhooks. Page key webhooks.

Key concepts

Term	Meaning
Webhook (subscription)	A rule: when an event of this kind happens, send it to this address.
Delivery	One attempt sequence to send one event to one webhook.
Signing secret	A whsec_ secret, shown once, used by the receiver to verify that a request came from this platform.
Receiving	The reverse direction: another system calls a flow's address.

Add webhook dialog

Field	Type	Default	Required	Description
Name	text	empty	Yes	The code is derived from it.
Event	text	empty	Yes	The event name to send, or * for every event. Letters, digits and _ . : -, up to 121 characters.
Address	text	empty	Yes	"A public https address." The dialog requires the text to start with https://. The server also refuses private and internal addresses.

A webhook starts switched off ("It starts switched off. Each event is sent as a signed POST, retried with growing waits, and parked for replay if it keeps failing."). On creation a dialog shows the signing secret once: "Copy this now. It is not shown again."

Tabs

Tab	Content
Webhooks	Columns Webhook (name, code), Event ("Every event" for *), Sends to, Status (On, Off). Row actions Switch on or Switch off, Send test, New secret (rotates, shows the new secret once), delete.
Delivery log	Status filter All, Waiting or retrying, Delivered, Failed for good. Columns Queued (time, webhook, event kind), Status (delivered, pending, failed for good), Attempts, Last answer (HTTP 200, or the error and "next try TIME"). Replay appears on failed-for-good rows.
Receiving	One row per flow: Flow, Address /api/v1/integration/flows/webhooks/CODE with the server base address, Protection (Signed - "Needs the signing secret" - or Open - "Open to anyone with the address"). Row action Protect with a secret or New secret.

Chips above the tabs: Webhooks, Switched on, Delivered (24h), Waiting or retrying (24h), Failed for good (24h).

What the receiver gets

POST /hooks/spark HTTP/1.1
Content-Type: application/json
User-Agent: SparkERP-Webhooks/1
webhook-id: msg_4812
webhook-timestamp: 1790000000
webhook-signature: v1,K5xq0...base64...

{"id":"evt_6b1f0c2e-...","type":"order.created","occurredAt":"2026-10-05T09:00:00Z","data":{"id":"SO-1001"}}

The signature is v1, followed by the base64 HMAC-SHA256 of webhook-id, a dot, webhook-timestamp, a dot and the body, keyed with the secret string in UTF-8 (the Standard Webhooks scheme). Receivers should also reject an old timestamp. The webhook-id is stable per delivery; the event id is shared by every delivery of one event.

Delivery behaviour

Rule	Value
Timeout per attempt	10 seconds; connect timeout 5 seconds; redirects not followed.
Success	Any HTTP 2xx.
Attempts	6 by default per delivery (the API accepts 1 to 20 through maxAttempts).
Retry delay	30 seconds doubling each attempt, capped at 6 hours, plus up to one fifth jitter. A Retry-After header (up to one hour) wins when longer.
Permanent failure	A 4xx answer other than 408 and 429 ends the delivery immediately as failed for good.
Switched off	A pending delivery for a webhook switched off becomes failed for good with "the webhook was switched off; replay it after switching it on".
Large events	An event over 256 KB is not sent; a failed-for-good entry says "the event is larger than 256 KB and was not sent".
Missing secret	"the signing secret is missing; rotate it".

Procedure

1. Select Add webhook, Name Partner orders, Event order.created, Address https://partner.example.com/hooks/spark. Select Add webhook and copy the secret.
2. Give the secret to the partner.
3. Select Switch on, then Send test. A notice reads "Test delivered (HTTP 200)." or "Test not delivered: REASON". The test sends the event kind webhook.test with {"message":"This is a test from Spark ERP."}.
4. Open the Delivery log to confirm.

Permissions

integration.webhook: view (list, delivery log) and manage (create, switch, rotate, test, delete, replay). Inbound secrets are set with integration.flow / manage.

API and CLI

Purpose	Request
List with 24 hour counts	GET /api/v1/integration/webhooks
Create	POST /api/v1/integration/webhooks with {"code":"partner-orders","name":"Partner orders","eventType":"order.created","targetUrl":"https://partner.example.com/hooks/spark","maxAttempts":6}; the response includes secret once
Switch	POST .../{code}/active with {"active":true}
Rotate	POST .../{code}/rotate-secret
Test	POST .../{code}/test
Delete	DELETE .../{code}
Deliveries	GET .../deliveries?webhook=&status=&pageIndex=&pageSize= (page size up to 100)
Replay	POST .../deliveries/{id}/replay

There is no erp command for webhooks. A dead delivery can also be replayed from Failed Items. See Send events with webhooks for an end-to-end example.

Errors and troubleshooting

Message	Cause	Fix
"the code must be lower-case letters, digits and dashes"	Bad code.
"choose the event to send, or * for every event"	Event empty or malformed.
"the webhook address must use https" / "...points to a private or internal network, which is not allowed" / "...must not contain credentials"	Address check.	Use a public https address.
"there is already a webhook with the code X" (409)
"only a dead delivery can be replayed" (409)	Replay on a delivery that is not failed for good.
"secret storage is not available, so webhooks cannot be signed"	The tenant secret store is not configured.	Ask the operator.
"the receiver answered HTTP 4xx/5xx"	The receiving system refused.	Fix the receiver, then Replay.

Folder Watches

A folder watch looks in a folder on an SFTP server at an interval. Each new file is announced as the event sftp.file.arrived, which starts flows whose trigger is "A file arrives on an SFTP server". A managed watch also moves each file through processing, processed and failed folders.

Where to find it

Studio Explorer > Workspace > Integrations > Folder Watches. Page key file-watches.

Add folder watch dialog

Field	Type	Default	Required	Description
Name	text	empty	Yes
SFTP connection	select	none	Yes	Lists SFTP connections only.
Folder	text	/	Yes	For example /incoming.
File names	text	*	Yes	* matches anything, ? one character. Example orders-*.csv.
Look every (seconds)	number	300	Yes	At least 30; the API accepts 30 to 86400. The helper reads "Looks every 5 minutes. At least 30."
Acknowledgement ending (optional)	text	empty	No	For example _ACK: employee_20260926_ACK.csv answers employee_20260926.csv. Each answer is announced as sftp.ack.received with outcome ACCEPTED, REJECTED, PARTIAL or UNKNOWN. 1 to 30 letters, digits, dot, dash or underscore.
Manage the files (move them while they are handled)	switch	off	No	Shows the four fields below.
Processing folder	text	/processing	No	Where a file is moved while flows handle it. Empty keeps the file in place.
Processed folder	text	/processed	Yes when managed	Must start with /.
Failed folder	text	/failed	No	Where files go when a flow did not succeed.
Keep the record of finished files (days)	number	90	Yes when managed	1 to 3650. "Only the record is forgotten. Files on the server are never deleted."
Watching	switch	on

The watched, processing, processed and failed folders must all differ. Folders are absolute paths without ... Naming a processing or failed folder without a processed folder is refused.

Behaviour

• Files already in the folder at the first look are not announced; only files that arrive afterwards start flows, once each. Changing the connection, folder or file pattern starts again from a first look.
• A managed file moves to the processing folder, is announced there, and when the flows that handled it finish it moves to processed, or to failed if one did not succeed. A file that arrives while no flow is listening stays where it is until a flow is switched on.
• At most 200 new files are announced per look. An acknowledgement file larger than 1 MB is not read.
• The event payload: watch, connection, directory, name, path, size, modifiedAt. The acknowledgement event adds originalName, outcome, detail.

Grid and actions

Columns: Watch, Folder (connection: directory (pattern)), Looks (for example "every 5 minutes"), State (red chip with the last error, green "Watching - N files", or Off). Chips: Watches, Failing. Row actions: Look now (reports "Looked in the folder: N matching files, M new." or "Could not look: REASON"), Files (managed watches only: each file with status detected, processing, completed, failed, its path and error) and delete.

File statuses

DETECTED then PROCESSING then COMPLETED or FAILED.

Permissions

integration.flow: view for lists, files and health; manage for saving, deleting and Look now.

API and CLI

Purpose	Request
List	GET /api/v1/integration/file-watches
Save	PUT /api/v1/integration/file-watches/{code}
Delete	DELETE .../{code}
Look now	POST .../{code}/look-now
Files	GET .../{code}/files?status=DETECTED|PROCESSING|COMPLETED|FAILED (200 newest)
File trace	GET .../{code}/files/{id}/trace (the file and every flow run started for it)
Health	GET .../health

{
  "name": "Partner orders",
  "connectionCode": "partner-sftp",
  "directory": "/incoming",
  "filePattern": "orders-*.csv",
  "pollSeconds": 300,
  "active": true,
  "processingDir": "/processing",
  "processedDir": "/processed",
  "failedDir": "/failed",
  "retentionDays": 90,
  "ackSuffix": ""
}

Command	Purpose
erp file-watch list	List.
erp file-watch save <code> --name <name> --connection <connectionCode> --directory <dir> [--pattern <glob>] [--poll-seconds <n>] [--active true|false] [--processing-dir <dir>] [--processed-dir <dir>] [--failed-dir <dir>] [--retention-days <n>] [--ack-suffix <suffix>]	Create or update.
erp file-watch delete <code>	Delete.
erp file-watch files <code> [--status ...]	Files of a managed watch.
erp file-watch trace <code> <fileId>	Why a file ended failed.

Errors and troubleshooting

Message	Cause
"the connection must be an SFTP connection"	Wrong connection type.
"choose an existing connection"	Unknown code.
"look every 30 seconds to 24 hours"	Interval out of range.
"the watched folder, processing, processed and failed folders must all be different"
"name the processed folder too: managing files needs to know where finished files go"
"the processed folder must be a folder path starting with /"
"the acknowledgement ending is 1 to 30 letters, digits, dot, dash or underscore, for example _ACK"
"keep the record of finished files for 1 to 3650 days"
State chip with an error	The server was unreachable or the host key is not trusted. Check the connection and pin the host key on Connections.

Poll Triggers

A poll trigger asks a web service for a list at an interval and announces each new item as the event poll.item.new. Optionally it also announces changed items as poll.item.updated. Flows use the triggers "A new item appears in a web service" and "An item in a web service changes".

Where to find it

Studio Explorer > Workspace > Integrations > Poll Triggers. Page key poll-triggers.

Add poll trigger dialog

Field	Type	Default	Required	Description
Name	text	empty	Yes
Web-service connection	select	none	Yes	REST connections only. Address and sign-in come from the connection.
Path that lists the items	text	empty	Yes	Added to the connection address, for example /contacts?updated_since=${since}. ${since} becomes the time of the last successful look. At most 500 characters; no scheme.
Where the list is in the answer	text	empty	No	Dotted path such as data.items. Empty when the answer is the list itself.
Field that identifies an item	text	id	Yes	Must differ for every item. Items without it are ignored and counted.
Where the next page is named (optional)	text	empty	No	For services that answer page by page, for example paging.next. Empty reads only the first page.
Send it back as (optional)	text	empty	No	A query field name when the value is a cursor. Empty when the value is the next address. Disabled without a next-page path.
Most pages per look	number	1	When a next-page path is set	1 to 20.
Look every (seconds)	number	300	Yes	30 to 86400.
Also announce items that change	switch	off		Announces poll.item.updated.
Watching	switch	on

Behaviour

• Items already present at the first look are not announced. Each item that appears afterwards is announced once.
• Changing the connection, path, list path, id field, next-page path, cursor field or page limit starts again from a clean first look.
• Limits: 5000 items read per look, 200 announced per look, 50000 remembered ids per trigger (the oldest are forgotten; an old item that reappears would be announced again), 30 seconds per request. A next-page address that points outside the connection's own address is refused.
• Event payload: trigger, connection, id, item (the whole item).

Grid and actions

Columns Trigger, Looks at (connection: path), Looks, State. Look now reports "Found N items, M new." with a note when items had no id, or "Could not look: REASON", and shows the first item so the paths can be checked against the real answer. Chips: Triggers, Failing.

Permissions

integration.flow: view and manage.

API and CLI

GET /api/v1/integration/poll-triggers, PUT .../{code}, DELETE .../{code}, POST .../{code}/look-now (returns itemsFound, announced, itemsWithoutId, sample, error).

{
  "name": "New contacts",
  "connectionCode": "crm",
  "path": "/contacts?updated_since=${since}",
  "itemsPath": "data.items",
  "idField": "id",
  "nextPath": "paging.next",
  "cursorParam": "cursor",
  "maxPages": 5,
  "notifyUpdates": false,
  "pollSeconds": 300,
  "active": true
}

Command	Purpose
erp poll-trigger list	List.
erp poll-trigger save <code> --name <name> --connection <connectionCode> --path <path> [--items-path <jsonPath>] [--id-field <field>] [--notify-updates true|false] [--poll-seconds <n>] [--active true|false] [--next-path <jsonPath>] [--cursor-param <name>] [--max-pages <n>]	Create or update.
erp poll-trigger delete <code>	Delete.
erp poll-trigger look-now <code>	Check now and report.

Errors and troubleshooting

Message	Cause
"choose an existing connection" / "the connection must be a web-service connection"
"look every 30 seconds to 24 hours"
"read 1 to 20 pages per look"
"to read more than one page, say where in the answer the next page is named"	maxPages above 1 without a next-page path.
"give the path that lists the items, such as /contacts?limit=50"	Path empty, too long, with control characters or containing a scheme.
"Could not look: ..."	The service refused the call or the answer has no list at the given path.

Synchronization

Keeps records in the platform and an outside system in step. A preview compares both sides and reports the differences without changing anything. A run copies changes across and leaves real disagreements for a person to settle. Side A is a platform entity; side B is an outside web service read through a connection and written through flows, so retries, failed items and audit apply to every outside write.

Where to find it

Studio Explorer > Workspace > Integrations > Synchronization. Page key integration-syncs.

Definition

The dialog New synchronization takes a Name, a Code ("Lower-case letters, digits and dashes", 2 to 63 characters, fixed after creation) and the Definition (JSON). Changing the definition switches the synchronization off until it is checked again.

Key	Type	Default	Required	Description
direction	A_TO_B, B_TO_A, BIDIRECTIONAL	BIDIRECTIONAL	No	A_TO_B is platform to outside.
policy	A_WINS, B_WINS, LATEST_TIMESTAMP, FIELD_OWNER, MANUAL_REVIEW	MANUAL_REVIEW	No	What happens when both sides changed a field.
fields	list of names	none	Yes	The fields kept in step. At most 100; letters, digits and underscores, starting with a letter.
owners	object field to A or B	{}	For FIELD_OWNER	At least one owner when the policy is FIELD_OWNER. The field must be listed in fields.
createInA, createInB	boolean	true	No	Whether missing records are created on each side.
sideA.entity	string	none	Yes	Platform entity.
sideA.keyField	string	none	Yes	Field holding the shared key.
sideA.updatedField	string	none	For LATEST_TIMESTAMP
sideA.fieldMap	object	{}	No	Shared field name to the entity's own field.
sideB.connection	string	none	Yes	A REST connection code.
sideB.path	string	none	Yes	Starts with / or ?; where the list is read.
sideB.itemsPath	string	empty	No	Where the list sits in the answer.
sideB.keyField	string	none	Yes
sideB.updatedField	string	none	For LATEST_TIMESTAMP	Needed on both sides for that policy.
sideB.fieldMap	object	{}	No
sideB.nextPath, cursorParam, maxPages		empty, empty, 1	No	Paging as for poll triggers; maxPages 1 to 20.
sideB.createFlow, updateFlow	flow codes	none	One of them unless B_TO_A	The flows that write to the outside system. Each receives operation, key and values.

Policies: MANUAL_REVIEW leaves disagreements for a person, A_WINS is the platform, B_WINS the outside system, LATEST_TIMESTAMP needs updatedField on both sides, FIELD_OWNER uses owners.

{
  "direction": "BIDIRECTIONAL",
  "policy": "MANUAL_REVIEW",
  "fields": ["name", "department"],
  "owners": {},
  "createInA": true,
  "createInB": true,
  "sideA": {
    "entity": "Employee",
    "keyField": "employeeNo",
    "updatedField": "updatedAt",
    "fieldMap": { "name": "fullName" }
  },
  "sideB": {
    "connection": "hr-api",
    "path": "/employees",
    "itemsPath": "data",
    "keyField": "id",
    "updatedField": "modified",
    "createFlow": "create-employee-outside",
    "updateFlow": "update-employee-outside"
  }
}

Grid and actions

Columns: Synchronization (name, code, direction in words - "SPARK to outside", "Outside to SPARK", "Both ways" - field count and policy), Status (On, Off or "Needs attention" with the definition problems as tooltip), Changed.

Action	Effect	API
Preview	Compares both sides; disabled when the definition has problems. Shows the counts and sentences such as "SPARK has 120 records, the outside system has 118; 110 match.", "N only in the outside system", "N only in SPARK", "N differ in some field", duplicate keys. "Nothing was changed."	POST /api/v1/integration/syncs/{code}/run with {"preview":true}
Run	Applies changes. Enabled only when the synchronization is on.	POST .../{code}/run with {"preview":false}
Disagreements	Lists open disagreements (record key, field, the platform value and the outside value). Use SPARK or Use outside settles one.	GET .../{code}/conflicts?status=OPEN, POST .../{code}/conflicts/{id}/resolve with {"winner":"A"} or "B"
History	The last runs: mode, status, who and when, created, updated, disagreements, failed.	GET .../{code}/runs?limit=
Edit, switch, Delete	Edit the definition; the switch enables or disables; Delete removes it and everything it remembers.	PUT .../{code}, POST .../{code}/enable, POST .../{code}/disable, DELETE .../{code}

Enabling a synchronization that requires go-live approval returns 202 PENDING_APPROVAL and creates a request on Go-Live Approvals.

Statuses

Run status: RUNNING, SUCCESS, PARTIAL, FAILED; mode PREVIEW or RUN. Disagreement status OPEN or RESOLVED. The synchronization keeps the last agreed values so it can tell which side changed.

Limits

Up to 5000 records per side per run (more is refused: "the entity has more than 5000 records, more than one run reads"); at most 5000 writes per run; 30 seconds per outside request. A synchronization already running refuses a second run ("this sync is already running").

Permissions

integration.sync: view, manage (save, enable, disable, delete, go-live requirement), execute (run, preview, settle disagreements).

CLI

erp sync list, erp sync save <code> <definition.json> --name <name>, erp sync enable|disable <code>, erp sync run <code> [--preview], erp sync require-golive-approval <code> on|off.

Errors and troubleshooting

Message	Cause
"the code is lower-case letters, digits and dashes, 2 to 63 characters"
"give the sync a name (up to 200 characters)"
"direction must be A_TO_B, B_TO_A or BIDIRECTIONAL" / "policy must be A_WINS, B_WINS, LATEST_TIMESTAMP, FIELD_OWNER or MANUAL_REVIEW"
"name the fields to keep in step, for example ["name", "department"]"	fields empty.
"sideA needs the entity to keep in step" / "sideA needs the field that holds the shared key"
"sideB needs the connection to read through" / "sideB path must start with / and is where the list is read"
"sideB needs a flow that creates or updates records there (createFlow, updateFlow), because SPARK writes to the outside system through flows"
"the policy LATEST_TIMESTAMP needs updatedField on both sides"
"the policy FIELD_OWNER needs an owner (A or B) for at least one field"
"the sync is switched off; preview it, then switch it on"	Run on a disabled synchronization.
"this conflict was already settled"

Queues

A queue holds messages until a flow has handled each one. A flow puts a message on with the queue.publish action; flows whose trigger is the event queue.message.received handle it. A failed message is tried again after a growing delay and, when its attempts are used up, becomes dead, where it can be replayed. A queue can be bridged to an outside broker. Messages wait safely while no flow is listening.

Where to find it

Studio Explorer > Workspace > Integrations > Queues. Page key integration-queues.

New queue dialog

Field	Type	Default	Required	Description
Name	text	empty	Yes
Code	text	slug of the name, up to 63 characters	Yes	Lower-case letters, digits and dashes. "Flows use this to choose the queue. It cannot change later."
Attempts	number	5	Yes	1 to 20, then the message is dead.
First retry after (seconds)	number	30	Yes	1 to 86400. Doubles on each attempt, capped at 6 hours.
Keep finished messages (days)	number	30	Yes	1 to 3650.
Outside message broker	select	Not bridged	No	"Send this queue's messages to a broker" (OUT) or "Bring a broker's messages onto this queue" (IN).
Broker connection	select	none	With a bridge	Kafka, RabbitMQ, SQS, Azure Service Bus or Pub/Sub connections.
Topic or queue to send to / read from	text	empty	With a bridge	Must already exist on the broker; the platform never creates one. Letters, digits and . _ - : /, up to 300 characters.
Check the broker	button			Tests the connection and destination and prints a message in words.
Switched on	switch	on		A queue that is off takes no new messages.

A queue and a broker bridge: an OUT queue sends each message to the broker and counts it done once the broker accepted it; if the broker refuses, the message is retried and finally goes dead, and the queue shows a Broker problem chip with the reason. An IN queue acknowledges each broker message only after it is stored, so a crash never loses one; a message can arrive twice, so handlers should tolerate that.

Grid and dialogs

Columns: Queue (name, code, attempts, bridge phrase such as "sent to orders.out on kafka-main"), Messages ("Empty", or "N waiting, N being handled, N dead", with a "needs attention" chip when dead messages exist), Done, Status (On or Off, Broker problem), Changed.

Action	Effect	API
Messages	Dialog with tabs All, Waiting, Being handled, Dead, Done; per message: id, state, attempts, due time, payload and last problem. Replay on a dead message gives it a fresh set of attempts.	GET /api/v1/integration/queues/{code}/messages?status=&limit=, POST .../{code}/messages/{id}/replay
Send test	Puts a JSON message on the queue. Disabled when the queue is off. "The message is not valid JSON."	POST .../{code}/publish with {"message":{...},"delaySeconds":0,"dedupeKey":"..."}
Edit	Changes everything except the code.	PUT /api/v1/integration/queues/{code}
Delete	Removes the queue and its finished and dead messages. Refused while messages wait.	DELETE .../{code}
Trace	The message plus every flow run any attempt started.	GET .../{code}/messages/{id}/trace

Message statuses

Status	Label	Meaning
READY	waiting	Due to be taken (after delaySeconds).
IN_FLIGHT	being handled	Taken by a flow run.
DONE	done	Handled.
DEAD	dead	Attempts exhausted. Replay to try again.

The event payload a flow receives for queue.message.received: queue, messageId, attempt, message.

Procedure

1. Select New queue: Name Orders, leave the defaults (5 attempts, 30 seconds).
2. Build a flow whose trigger is the ready-made event "A message is taken from a queue" (queue.message.received) and switch it on.
3. Select Send test and send {"orderId":"A-1001"}.
4. Open Messages. The message moves from waiting to done. If the flow fails it returns with a growing delay and ends dead after five attempts.

Limits

Message payload at most 256 KB; delay 0 to 30 days; at most 100000 waiting messages per queue ("the queue already holds 100000 waiting messages").

Permissions

integration.queue: view (list, messages, trace), manage (save, delete), execute (publish, replay).

API and CLI

{
  "name": "Orders out",
  "maxAttempts": 5,
  "retrySeconds": 30,
  "retentionDays": 30,
  "enabled": true,
  "bridgeDirection": "OUT",
  "bridgeConnection": "kafka-main",
  "bridgeDestination": "orders.out"
}

Sent with PUT /api/v1/integration/queues/orders-out. A request that omits all three bridge fields leaves the bridge unchanged; to remove a bridge send all three as empty strings. The publish response is {"messageId":N,"duplicate":false}.

Command	Purpose
erp queue list	List with counts.
erp queue save <code> --name <name> [--max-attempts <n>] [--retry-seconds <n>] [--retention-days <n>] [--enabled true|false] [--bridge-direction IN|OUT --bridge-connection <code> --bridge-destination <topic-or-queue>]	Create or update.
erp queue publish <code> --message <json-string-or-@file> [--delay-seconds <n>]	Put a message on.
erp queue messages <code> [--status READY|IN_FLIGHT|DONE|DEAD]	List messages.
erp queue replay <code> <messageId>	Replay a dead message.
erp queue trace <code> <messageId>	Why a message ended dead.
erp connection broker-test <code> [--destination <topic-or-queue>]	Test a broker connection.

Errors and troubleshooting

Message	Cause
"the code uses lower-case letters, digits and dashes (up to 63 characters)" / "give the queue a name"
"attempts are between 1 and 20" / "the first retry delay is between 1 second and 1 day" / "finished messages are kept between 1 and 3650 days"
"a bridge needs a direction, a connection and a destination together"
"the bridge direction is IN (from the broker) or OUT (to the broker)"
"the connection "X" is a TYPE connection; choose a message-broker connection (...)"	Wrong connection type.
"the queue "X" is switched off"	Publish to a disabled queue.
"the message is larger than 256 KB" / "the delay is between 0 and 30 days"
"the queue still has N message(s) waiting or being handled" (409)	Delete refused.
"no dead message ID on the queue X" (404)	Replay of a message that is not dead.

Related

Overview, Flows, Connections, Move between environments, Send events with webhooks.