“Could you type this up, please?” In many businesses, that is how an enquiry travels from the website into the job. The message arrives by email, someone copies name, phone number and request by hand into the order or industry software, and only there does the real work begin, with appointment, quote and callback. That costs time and produces typos at exactly the point where a new customer deals with the business for the first time. XICflow can additionally send every new enquiry to an https address provided by your program, and it attaches a signature to every call. This article explains when that pays off, which details are transmitted, why the signature proves that the data really comes from your website, and what happens if the program does not answer. It also covers the obligations under the General Data Protection Regulation that come with the receiving service, and a procedure for the first test run.
When forwarding pays off
For many businesses, the email notification is enough.
It goes to an address of your choice, contains name, email, phone, message and all custom fields, and clicking “Reply” reaches the person who sent the enquiry directly (XICflow documentation). If only a few enquiries arrive each week and no program processes them further, that is the simpler route; what matters more than the transfer method is then the response time, as described in the article Answering enquiries fast: response times that win jobs. The picture changes when customers, jobs and appointments are managed in a program anyway. Then every enquiry is captured a second time, by hand and with the risk that a digit in the phone number slips or a message stays buried in the inbox. Exactly this step disappears when the website hands the data over directly.
How widespread such programs are is shown by the European Union survey on the use of information technology in enterprises. Of small enterprises with 10 to 49 employees (Eurostat), 41.08 percent (Eurostat) used enterprise resource planning software, ERP for short, in 2025, and 24.69 percent (Eurostat) used customer relationship management software, CRM for short. The survey only covers enterprises with at least ten employees in selected economic sectors (Eurostat); for micro businesses with just a handful of staff it provides no figure. It does show, however, that in many businesses customer data lives in a dedicated system and not only in an inbox. Whether forwarding pays off therefore depends less on size than on three questions: Is there a program in which the enquiry is processed further? Can this program accept data via an https address? And do enough enquiries come in for the retyping to add up noticeably?
- A trade business creates every enquiry as a job in its order software, with customer number, property address and follow-up date.
- A property management company collects damage reports from the form in its management program and assigns them to the property there.
- A restaurant transfers group enquiries into its reservation system instead of copying them out of the inbox – a good match for the group booking page for Christmas parties.
- A service business with several staff distributes enquiries through a customer relationship management system that records who is responsible and how far each case has got.
- A business with dedicated forms for existing customers has service requests arrive directly in its ticket or order system, as described in the article on service forms for existing customers.
What XICflow hands over to your program
Forwarding is set up in the “Requests” area. Below the notification address you will find the field “Automation webhook (URL)”.
There you enter the address your program provides for incoming data; only https addresses are accepted, and if you do not need forwarding, you leave the field empty (XICflow documentation). From the moment you save, XICflow sends every new enquiry as JSON via POST to this address, in addition to the list and the email. What gets transmitted is the occasion (“form.submission”), the identifier of the website, the time of arrival and the enquiry itself with name, email, phone, message, address, all custom fields and the name of the form (XICflow documentation). The address applies per website. If you look after several websites, you set it up for each one separately and can, for example, send the enquiries of two locations to two different programs.
{
"event": "form.submission",
"site": "your-website",
"submitted_at": "2026-10-25T08:14:03+00:00",
"submission": {
"id": "3f9c2a1e-7b4d-4c8e-9a51-2d6e8f0b1c47",
"name": "First name Last name",
"email": "contact@client.invalid",
"phone": "030 23125 412",
"message": "Please send a quote for painting two rooms.",
"url": null,
"fields": {
"Property type": "Flat",
"Preferred date": "November"
},
"form": "Quote request"
}
}A few details help with matching in the program. The identifier under “id” belongs to exactly one enquiry and is suitable for recognising a call that arrives twice. Custom fields appear with their label under “fields”; fields left empty are not transmitted (XICflow documentation). A form can contain up to 40 custom fields, a message is cut after 5,000 characters and a single custom field after 2,000 characters (XICflow documentation). If your program has fixed columns, it makes sense to name the form fields exactly as they are called there – that saves a translation table on the receiving side. Two standards describe what happens technically: POST asks the target address to process the enclosed content according to its own rules (RFC 9110), and JSON exchanged between systems that are not part of a closed ecosystem must be encoded in UTF-8 (RFC 8259). Umlauts and accented characters in names and messages therefore arrive unchanged, provided the program reads UTF-8.
Why the signature proves authenticity
The receiving address of your program has to be reachable from the internet, otherwise XICflow could not call it. That also means anyone who knows it can, in principle, call it.
The security initiative OWASP therefore describes a webhook endpoint as a public, unauthenticated POST handler unless the authentication is added separately (OWASP). Without a check, someone could write fake “enquiries” into your program: with invented names, with links to unknown sites or simply in large numbers. In a customer management system from which quotes and callbacks are generated, that is more than a nuisance.
The check is handled by a procedure called HMAC, which RFC 2104 describes as a mechanism for message authentication using cryptographic hash functions (RFC 2104). The principle: two parties share a secret and use it to validate information transmitted between them (RFC 2104). XICflow generates this “Signing secret” as soon as you save an address for the first time and shows it below the field (XICflow documentation). For every call, XICflow uses the secret to compute a check value over the timestamp and the content and sends it along in a header. Your program recomputes it with the same secret. If both values match, the call comes from someone who knows the secret, and the content was not altered in transit. The hash function used is SHA-256, whose output is 256 bits long (RFC 4868). Germany’s Federal Office for Information Security lists SHA-256 among its recommended hash functions and regards HMAC as secure when such a hash function is used and the key is at least 128 bits long (BSI TR-02102-1).
X-XICflow-Timestamp
The time of the call as a Unix timestamp in seconds. It is part of the signed text and therefore cannot be swapped without the check failing.
X-XICflow-Signature
The check value after “sha256=”, computed over the timestamp, a dot and the unchanged body. Your program recomputes it and compares (XICflow documentation).
Signing secret
Shown in XICflow below the webhook field and taken over with “Copy”. It does not travel with the call but is kept separately on both sides.
The signature has two limits worth knowing. First, it proves authenticity but does not encrypt the content; without encryption, anyone on the network path could read along (OWASP). That is why XICflow only accepts https addresses. Encryption is provided by TLS, which according to its specification is designed to prevent eavesdropping, tampering and message forgery (RFC 8446); for webhook endpoints, OWASP recommends TLS 1.2 or higher with a certificate from a trusted authority (OWASP). Second, a valid signature says who sent the data, not that its content is safe (OWASP). Whatever someone types into the form remains outside input and is treated in the program like any other input.
How the receiving program checks
How the check is set up depends on how your program accepts data. If it offers its own receiving address with signature verification, you enter the secret there and follow the vendor’s instructions.
If you run a small receiving endpoint yourself or have one built, implement the check in these steps; the structure and fields of the call are described in the XICflow API documentation.
- Keep the raw content. Read the body of the call exactly as it arrives, before a framework parses it as JSON. OWASP explicitly advises you to supply the raw request body before your framework parses it (OWASP); anyone who parses and rewrites it first changes whitespace or order, and the check fails.
- Read the headers. “X-XICflow-Timestamp” carries the timestamp, “X-XICflow-Signature” the check value after “sha256=” (XICflow documentation).
- Recompute. Build HMAC-SHA256 over the timestamp, a dot and the unchanged body, with the secret as the key (XICflow documentation). The secret is used as exactly the character string XICflow displays, without conversion.
- Compare in constant time. Compare your own value with the delivered one using a function whose running time does not depend on where two values differ.
- Check the time window. Reject calls whose timestamp differs from your own clock by more than a small tolerance (OWASP). This prevents a captured call from being replayed later.
- Detect duplicates. Store the identifier from “submission.id” and do not process another call with the same identifier a second time.
- Answer quickly. Acknowledge receipt immediately and do the actual processing afterwards, for example through a queue (OWASP).
import hashlib
import hmac
import time
# Character string from the “Signing secret” field, taken over unchanged
# and loaded from a protected configuration, not from the source code
SECRET = load_secret("xicflow_webhook")
TOLERANCE_SECONDS = 300 # freely chosen sample value
def receive_enquiry(headers, raw_body: bytes) -> int:
timestamp = headers.get("X-XICflow-Timestamp", "")
signature = headers.get("X-XICflow-Signature", "")
if not timestamp.isdigit() or not signature.startswith("sha256="):
return 401
if abs(time.time() - int(timestamp)) > TOLERANCE_SECONDS:
return 401
expected = hmac.new(
SECRET.encode("utf-8"),
timestamp.encode("ascii") + b"." + raw_body,
hashlib.sha256,
).hexdigest()
if not hmac.compare_digest(expected, signature[len("sha256="):]):
return 401
enqueue(raw_body) # processing afterwards, not within this call
return 200For the comparison in step 4, Python provides the function “compare_digest”; according to its documentation it is built to prevent timing analysis and is therefore appropriate for cryptography (Python documentation). In PHP, “hash_equals” does the same job; an ordinary comparison, by contrast, takes more or less time depending on the position of the first difference and so leaks information about the secret (PHP manual). For the answer to the sender, OWASP recommends a clear scheme: 200 only once the delivery is durably stored or queued, 400 for malformed content and 401 for a wrong signature, each without technical detail in the response body (OWASP). If the signature is missing or does not match, the response should not reveal why either (OWASP).
When the check fails
What happens when a call fails
Your program has five seconds for each call (XICflow documentation). If it does not answer or is unavailable at that moment, the enquiry still stays in your list; XICflow does not try a second time (XICflow documentation).
Behind this is a clear division of labour: the website stores the enquiry regardless of forwarding, the email notification also runs separately, and forwarding is an additional copy. If the copy fails, the enquiry is missing from the program – but it is not lost. That leads to a simple rule: the list in XICflow is the source, the program is the workplace. XICflow does not call addresses inside a private network for security reasons (XICflow documentation). The background: according to OWASP, a service that delivers data to user-supplied addresses is a tool that attackers will try to aim at internal networks (OWASP). A program that is only reachable on the office network therefore needs a receiving address that can be reached from the internet via https.
Scroll table sideways
| Situation | What XICflow does | What you do |
|---|---|---|
| Program does not answer within five seconds | Ends the call, the enquiry stays in the list | Set up the receiver to acknowledge at once and process afterwards |
| Program unavailable due to maintenance | No second attempt, email notification as usual | Reconcile list and program after the maintenance |
| Address without https or faulty | Does not save it and shows “Please enter a valid https URL.” | Copy the address from the program again |
| Address points into an internal network | Does not call it | Use an https address reachable from the internet |
| Secret regenerated, receiver still checks the old value | Signs with the new value, the receiver rejects the call | Store the new value at once, add rejected enquiries from the list |
| Entry filtered out by the spam protection | Does not store it and does not forward it | Nothing; send test enquiries with real details |
Two routes are available for reconciling. The list loads the 500 most recent submissions (XICflow documentation), and the CSV export covers up to 5,000 entries, starting with the most recent, archived ones included (XICflow documentation). By default, enquiries are kept for 180 days and then deleted automatically (XICflow documentation). Reconciliation therefore belongs in a fixed rhythm, for example once a week and after every maintenance of the program, and not only at year end. What becomes of an enquiry in the program and how long it stays there follows its own deadlines; that is covered in the article Keep or delete website enquiries: deadlines at year end.
Treat the secret like a login credential
Anyone who knows the signing secret can create calls that your program considers genuine.
The BSI puts it in general terms for all procedures of this kind: the authentication keys used must be protected as well as any other cryptographic secrets (BSI TR-02102-1). OWASP is more specific and recommends treating webhook secrets like database credentials (OWASP). In practice, this means the secret belongs in the protected configuration of the receiver or in a password manager, not in an email, not in a shared document and not in the source code.
In XICflow, owners, administrators and editors may change the notification address and the webhook, viewers may not (XICflow documentation). If you clear the address again, the secret is kept; enter the same address later and the check keeps working unchanged (XICflow documentation). If you suspect that the secret has become known, create a new one with “Regenerate”. The previous value stops working immediately, and calls to a receiver still checking the old value will fail. So store the new value with the receiver straight away.
- Take over the secret only via “Copy”; do not retype it.
- Store it in the protected configuration of the receiver, separate from the source code.
- Write neither the secret nor the header with the check value into logs, error messages or tickets (OWASP).
- Use the team roles to decide who may change the webhook.
- Each website has its own secret; a receiver for several websites verifies each website with the matching value.
- After a change of staff with access, or on suspicion, regenerate the secret and update the receiver at once.
Data processing with the receiving service
With forwarding, name, email address, phone number and message gain another recipient.
As soon as a provider operates the receiving program or the server for it – an online customer management system, an automation service that distributes the data further, or a data centre – it usually processes the enquiries on your behalf. Article 28 GDPR then applies: you may only use processors that provide sufficient guarantees for appropriate technical and organisational measures (GDPR). The basis is a contract that sets out, among other things, the subject matter and duration, the nature and purpose of the processing, the type of data and the categories of data subjects (GDPR). What such a contract looks like and how it fits into the record of processing activities is explained in the article Data processing agreements for your website vendors. If you operate the receiving endpoint entirely yourself, this contract is not needed; responsibility for its security then rests with you alone.
Three further obligations come with forwarding. First, data minimisation: personal data must be adequate, relevant and limited to what is necessary for the purpose (GDPR). A form that asks only for what the answer requires also forwards only that; how to build one is shown in the article From visit to enquiry: getting contact forms right. Second, security of processing: Article 32 expressly lists the encryption of personal data among the appropriate measures (GDPR). The webhook’s https requirement and the signature protect the transmission path; the program itself has to be protected by the receiver. Third, informing the people concerned: under Article 13, the privacy policy names, where applicable, the recipients or categories of recipients (GDPR). XICflow generates a privacy policy for every website that includes the notice on processing form data (XICflow documentation); check whether the receiving service is named there as well before you switch forwarding on.
The path to the first test run
- Get the receiving address. The matching address comes from the program that is meant to receive the enquiries (XICflow documentation). It starts with https and is reachable from the internet.
- Enter the address. In the “Requests” area, choose the website, paste the address into the field “Automation webhook (URL)” and save.
- Take over the secret. Take over the “Signing secret” now shown with “Copy” and store it in the protected configuration of the receiver.
- Switch on the check. Activate signature verification on the receiver or implement it following the steps above, and reject calls without a valid signature.
- Publish the website. Only a published website accepts enquiries; publish again after inserting a form (XICflow documentation).
- Send a test enquiry. With real details, without links in the message and no sooner than three seconds after the page has loaded, otherwise the spam protection filters the entry out (XICflow documentation). The form shows the confirmation even for filtered entries; what counts is a look at the list.
- Compare both sides. Is the enquiry in the list and in the program, with all fields and correct special characters? Only then is the connection finished.
- Schedule reconciliation. Set a fixed date on which list and program are compared, and name a person who takes care of it.
With XICflow, form, enquiry list, notification and forwarding sit in one place. What else the platform handles is shown in the overview of services; the list, notifications, export and the webhook field are explained in the Requests and team chapter of the documentation, and How it works explains how a website comes together in XICflow. Whether a forwarded enquiry turns into a job is then no longer a matter of technology but of the business’s reply – it simply gets going faster when nobody has to retype anything.