01 / CONNECT YOUR WORKFLOW
Choose the connection the work actually needs
An outbound webhook sends a notification from Flowboard to a receiver you control when a supported event occurs. It is useful when another system needs to react to a project, task or invoice change. It does not automatically create a two-way sync, map every field or import a full history. Your receiver still needs to decide how to process the notification and which downstream action is appropriate.
For work that stays inside Flowboard, start with the automation guides. For moving existing work into the workspace, use the importing guide. These are different jobs from maintaining a custom integration. Connected-app tiles marked Coming Soon are not a completed native connector; agree the available route with support before depending on one.
Automate inside the workspace
Use supported triggers, conditions and actions when the next step belongs in Flowboard.
Explore this workflow ↗Move an existing project
Review import coverage and run a representative pilot before moving the rest of your work.
Explore this workflow ↗02 / CONNECT YOUR WORKFLOW
Set up one outbound webhook
Sign in as an owner or admin and open the workspace's Integrations settings. Prepare an HTTPS endpoint you control before adding a subscription. Choose only the events the receiver needs and give the subscription a description that explains its purpose. Each workspace supports up to 20 webhook subscriptions.
Use a test workspace or disposable sample records for your first event. Receiving a test ping is one check; receiving and handling the event created by your actual workflow is the next. Keep the destination's business actions disabled until both checks pass, especially if an event could create a bill, send a message or update a client record.
Prepare the receiver
Accept an HTTP POST, retain the raw request body for signature verification and record a sanitized delivery result. Keep the webhook secret on the receiving server.
Create the subscription
Enter the destination URL, select the required event types and save a clear description in Integrations. Keep the generated secret in your server-side secret store.
Send the test ping
Use the subscription's test control. Inspect the reported result and your receiver's log; a network error or non-success response needs investigation.
Exercise the real event
Create or update a sample record through the specific workflow you intend to connect. Confirm the received event name, payload, verification result and downstream handling.
03 / CONNECT YOUR WORKFLOW
Start with the events your receiver can handle
Start with the task, project, invoice and time-entry events listed below. Event payloads can be small: an invoice notification may identify the invoice rather than contain every invoice field. Inspect the actual payload before designing the destination's data model or assuming a notification contains a complete record.
Run the operation you want to connect using a sample record, then inspect the notification at your receiver. Member-event delivery needs confirmation with support before use. Record the event name and fields your receiver expects so changes to the connection can be tested consistently.
| Event family | Event names | What to check |
|---|---|---|
| Tasks | task.created, task.updated, task.deleted | Exercise the particular create, update or delete operation your workflow uses. |
| Projects | project.created, project.updated | Confirm the project identifier matches the sample record. |
| Invoices | invoice.created, invoice.status_changed | Check the status transition and payload for your payment workflow. |
| Time | time_entry.created | Covers new time entries. Ask support about notifications for changes or deletions. |
04 / CONNECT YOUR WORKFLOW
Verify the signature against the raw body
Flowboard signs webhook request bodies with HMAC-SHA256 using the subscription secret. Calculate the digest from the exact bytes received and compare it with the supplied hexadecimal signature using a constant-time comparison. Parsing and then reserializing JSON can change the bytes and cause a valid signature to fail.
There is a current distinction between a manually triggered test and an actual event delivery. Test requests use X-Flowboard-Signature and X-Flowboard-Event headers; delivery requests use X-Webhook-Signature and X-Webhook-Event. Account for that distinction when testing your receiver. Neither a recognized header name nor a matching event label replaces signature verification.
| Request | Signature and event headers | Body shape |
|---|---|---|
| Test ping | X-Flowboard-Signature; X-Flowboard-Event | event set to ping, workspace_id and timestamp |
| Workflow delivery | X-Webhook-Signature; X-Webhook-Event | event name and data object |
05 / CONNECT YOUR WORKFLOW
Keep an eye on delivery after setup
Webhook delivery expects a successful 2xx response, applies a 10-second request timeout and tracks consecutive failures. A successful delivery resets the failure count. Ten consecutive failures disable the subscription. The Integrations interface exposes its active state, last successful delivery and failure count so an owner or admin can inspect a stalled connection.
If delivery stops, first verify the endpoint, receiver logs and subscription state. Fix the receiver before re-enabling a disabled subscription, then run a test and a representative workflow event again. Build downstream processing to tolerate duplicate or delayed notifications, and keep a way to reconcile important records. Keep a reconciliation process for missed events; automatic replay and exactly-once delivery are not available guarantees.
06 / CONNECT YOUR WORKFLOW
Plan a custom API connection
Owners and admins can create, list and revoke API keys in Integrations. A newly created key is displayed once. Subsequent listings show identifying information rather than the original full key. Treat any key as a server-side secret, name it for its purpose and revoke it when the connection is no longer needed.
Public REST API access is not currently self-serve. Contact the team before building a connection that reads or updates Flowboard records through an API. We can clarify the available authentication route, supported operations and any requirements for your specific connection.
Send the team the records you need to read or change, the direction of the connection, the expected frequency and the system you are connecting. Agree authentication, permitted operations, limits and a small acceptance test before implementation. Do not include a secret in that first message.
THE PRACTICAL DETAILS
Questions, answered.
Is there a public REST API I can use immediately?
Contact the team for custom REST API access. Public endpoint and authentication documentation is not currently available for self-serve integrations. Outbound webhooks are described in this guide.
Who can manage webhook subscriptions?
Workspace owners and admins manage API keys and webhook subscriptions. If those controls are unavailable, ask your workspace owner or support about the setup you need.
Does a successful test prove that my integration works?
It proves only that the test request received a successful response. Test pings and workflow events have different headers and payload shapes. Exercise a real sample event and confirm the receiver's downstream behavior too.
Can I use the connected-app tiles as installed integrations?
Tiles marked Coming Soon are not active native connections. Confirm a supported integration route with the team rather than treating a listed service as a completed connector.
What should I send with an integration question?
Tell us which system you are connecting, which Flowboard records it needs, whether it reads or changes them and how often it runs. Include a sanitized example payload if useful. Keep API keys and webhook secrets out of the message.