Webhooks

July 20, 2026

Summary

Flxpoint webhooks send an HTTPS POST to a URL you configure whenever a subscribed event occurs, optionally scoped to a single source or channel, so your systems can react to events like a fulfillment request entering processing.

Overview

A Flxpoint webhook sends an event to one of your services over HTTPS POST, so that system can act when something happens in Flxpoint (for example, a fulfillment request entering processing). Webhooks can be scoped to a specific source or channel, or left on for all.

Event-driven: fires on a subscribed event you choose.
HTTPS POST: event data is sent to your URL via HTTPS.
Source/channel scope: limit to one source or channel, or leave on for all.
Built to be resilient: handle events idempotently and asynchronously.

Creating a webhook

Click the settings gear in the bottom left of your screen.
Click Webhooks.
Click Add Webhook in the top right.
Fill in the required information (fields below).
Click Save.

Set up the webhook with the following fields:

Field	Detail
Name	A label for the webhook.
URL	The HTTPS endpoint that receives the event via POST.
Notification Email	Where notifications about the webhook go.
Subscribed Event	The event that triggers the POST to your URL.
Source / Channel (optional)	If the event relates to the chosen source or channel, its info is shared; leave blank for all.

Best practices

Practice	Why
Make processing idempotent	The same event can arrive more than once; handling it twice should be safe.
Process asynchronously	Queue incoming events so your endpoint responds quickly and does not time out.
Receive over HTTPS	The endpoint must accept HTTPS POST requests.

Important notes

Note: Event data is delivered by HTTPS POST to the URL you configure. A non-HTTPS or unreachable endpoint will not receive events.

Note: Choosing a Source or Channel limits the webhook to events on that object. Leave both blank to fire for all sources and channels.

Note: Design the handler to be idempotent: the same event may be delivered more than once, and duplicate processing should not cause problems.

Common issues

The webhook is not being received.

Confirm the URL is HTTPS and publicly reachable, that it accepts POST, and that the Subscribed Event and any source/channel scope actually match the events you expect.

A firewall is blocking Flxpoint's calls.

If you need to allowlist Flxpoint by IP, contact Support to confirm the current outbound details rather than assuming a fixed range: do not hard-code an IP that may change.

The same event fires more than once.

This is expected behavior for webhooks. Make your event handling idempotent (for example, dedupe on the event identifier) so repeats are harmless.

FulfillmentRequestProcessingEvent does not fire for auto-routed orders?

You may notice that webhooks for the FulfillmentRequestProcessingEvent are not triggered when fulfillment requests are automatically generated via auto-routing. This is currently a known issue where the event eligibility check occurs before the status identifier is fully associated with the record. If you rely on this webhook for automated workflows, you may need to monitor fulfillment request statuses manually or via the Flxpoint app until a platform update resolves the timing of this event trigger.

FAQs

What is a webhook used for?

To notify another one of your systems when an event happens in Flxpoint, so it can act: for example, when a fulfillment request enters processing.

How do I create one?

Go to the Settings gear (bottom left) → Webhooks → Add Webhook. Set Name, URL, Notification Email, and Subscribed Event, optionally choose a source/channel, then Save.

Can I limit a webhook to one source or channel?

Yes: select the source or channel during setup. Leave both blank to receive the event for all.

Can a webhook fire when an invoice is created?

Yes, if there is a subscribed event for it: choose that event when creating the webhook so your endpoint receives the payload.

Does Flxpoint send from a fixed IP I can allowlist?

Contact Support to confirm current outbound details before allowlisting; avoid hard-coding an address that may change.

Fulfillment Request Webhook Limitations with Auto-Routing

What it does

The FulfillmentRequestProcessingEvent webhook is designed to notify external systems whenever a new Fulfillment Request (FR) is created in Flxpoint. For most users, this occurs as part of an automated workflow where Distributed Order Management (DOM) routes an order to a source and auto-generates the FR.

Current limitation

Currently, the FulfillmentRequestProcessingEvent webhook may not fire for auto-generated fulfillment requests. This behavior stems from a technical mismatch during the event eligibility check where the system looks for a specific status ID that is not yet populated at the moment the FR is cloned and processed.

Note: This issue specifically impacts auto-routed orders. Manual fulfillment requests typically trigger the webhook as expected.

Monitoring and workarounds

How can I track FRs if the webhook doesn't fire?

Because the event eligibility check happens before the status ID is fully committed to the record, the webhook trigger remains inactive. We recommend the following manual monitoring steps in the interim:

Dashboard Monitoring: Regularly check the Fulfillment Requests tab in the Order Management section to monitor new auto-generated requests.
Manual Triggers: If an external system requires an immediate update, manually triggering an action on the FR may force the status update required for event processing.
API Polling: For technical teams, polling the Flxpoint API for new Fulfillment Requests is a more reliable alternative than relying on this specific webhook for auto-routed workflows at this time.

Back to API & EDI