Other Automation Platforms
FSRevs can connect to n8n and other automation services through standard HTTPS webhooks. If a platform can receive an HTTPS webhook, you can connect it without waiting for a dedicated connector.
For the native apps, use Connect FSRevs to Make or Connect FSRevs to Zapier. You can still use a platform’s generic webhook tools with the raw-webhook workflow on this page when that is intentional.
Receiving FSRevs activity and changing data in FSRevs are separate tasks. A webhook receives events. To create or update a Customer or send a request back into FSRevs, configure an authenticated API action using API Access and the API reference.
Setup checklist
Section titled “Setup checklist”- In the automation platform, create a webhook trigger and copy its production HTTPS URL.
- In FSRevs, open Integrations → Webhooks, choose Create Webhook, and enter that URL.
- Choose the Webhook owner, activity, Forms, and Review Flows that should send messages.
- Save the one-time signing secret in the receiving service or in a trusted verification gateway.
- Use Send Test in FSRevs and confirm that the platform receives the test message.
- Ask your technical partner to verify each message and prevent repeated activity from running the automation twice.
See Save and verify your signing secret for handling and verification guidance.
After the connection test, create one matching new event and check the resulting automation. A successful test confirms that the endpoint accepts the test; it does not prove that every filter, field mapping, or later action is correct.
Avoid an update loop
Section titled “Avoid an update loop”If the automation writes changes back to FSRevs, check whether those changes will trigger the same automation again. For example, an FSRevs Customer update sent to a CRM can return as another update from that CRM. Compare the relevant fields before writing and use stable source record IDs. If unexpected repeated updates begin, pause the automation and inspect the recent runs before reconnecting it.
For your technical partner: verify and process messages
Section titled “For your technical partner: verify and process messages”Where the platform supports code or middleware, verify the signature before the automation processes the message. Keep the raw request body available for verification. Store each Event ID after processing it; if the same ID arrives again, ignore it so the automation does not run twice.
Platform notes
Section titled “Platform notes”With n8n, use a Webhook trigger with its production HTTPS URL, then verify the signature in a Code step or trusted gateway before continuing the workflow.
Some automation plans do not expose the untouched request body or the code needed for HMAC verification. In that case, place a small trusted verification gateway in front of the platform. The gateway verifies the message, then forwards accepted data to the automation. The native FSRevs Make and Zapier apps manage their own verified trigger flow.
Recover a lost API response
Section titled “Recover a lost API response”This section applies only when your own application creates webhooks through the FSRevs API.
Create the webhook with a unique Idempotency-Key. If the response is lost, repeat the same request with the same key. FSRevs can return the protected original result, including the signing secret while it remains available and current access still permits the request.
If that result is no longer available and the secret was not saved, deliberately create a replacement with a new key or use the Portal’s rotate or replace controls. The API does not currently provide signing-secret rotation or Webhook URL replacement.