Skip to content
FSRevsFSRevs User Guide

Integrations — Getting Started

Integrations connect FSRevs with services your team already uses.

Choose the path that matches what you want to build:

Before you begin

Section titled “Before you begin”
  • Choose the FSRevs user who will own the connection. Their current permissions and assigned Locations determine what the integration can use.
  • Have an authorized manager enable that user’s API Access. A working Portal login alone does not enable integrations.
  • Decide whether the automation only reads or synchronizes data, or also sends customer messages. Review Customer Identity and Sending before building a sending automation.
  • For sending, have an eligible Review Flow or Custom Form and a destination you control for the first test.

If Integrations is missing, ask your workspace manager to check your API Access and permissions. See Roles & Permissions for the difference between responsibilities and Location access.

Start with a native automation app when possible

Section titled “Start with a native automation app when possible”

For most teams, the native FSRevs app for Make.com or FSRevs Zapier app is the simplest place to begin. Both offer ready-made triggers and actions without asking you to choose technical API permissions. They can start an automation from selected FSRevs activity, keep Customers in sync, and send Review Requests or Custom Forms.

Open Integrations, choose Create Reusable Make.com Connection or Create Reusable Zapier Connection, and follow the matching Make.com setup guide or Zapier setup guide.

Choose the right connection

Section titled “Choose the right connection”
Your goal Start here What it does
Build an automation in Make.com Connect FSRevs to Make.com Provides guided FSRevs instant triggers and actions
Build an automation in Zapier Connect FSRevs to Zapier Provides guided FSRevs triggers and actions
Let another application look up information or perform an action in FSRevs Set up API access, then use the API reference Gives the application a protected credential for approved operations
Send selected FSRevs activity to another service as it happens Create and verify webhooks Delivers signed messages to the service’s public Webhook URL

One integration can use both API calls and webhooks. A webhook does not use an API credential to deliver messages. Its signing secret serves a different purpose:

Value Purpose Used by
API credential Calls the FSRevs API External application
Webhook signing secret Confirms that a webhook message came from FSRevs Webhook receiver

Set up API access

Section titled “Set up API access”

Use this path for a custom application or technical partner. After creating a credential, use the API reference for exact routes, permissions, request fields, responses, and errors.

An Owner, Administrator, or other all-location manager can open Integrations → API Access and enable API Access for an eligible user. These managers may enable it for their own Portal account; other Portal users cannot enable themselves.

API-only users cannot sign in to the Portal. Portal access and API Access are separate. API credentials and webhooks always stay within their owner’s current FSRevs permissions.

The page shows each user’s current state:

  • Enabled — the user can have API credentials and own webhooks.
  • Disabled with history — API Access is off, but historical credential records remain.
  • Not configured — API Access is off and no credential records exist.

Turning API Access off immediately revokes current credentials and disables webhooks owned by that user. Turning it back on does not reactivate them.

Create a credential for a custom application

Section titled “Create a credential for a custom application”

Open Integrations → API Access, choose Manage credentials for the appropriate user, and create a named credential for the application. Enabling API Access by itself does not create a credential.

FSRevs shows the complete credential only once. Copy the numeric prefix, | character, and secret together, then store the value securely. Use Replace Connection Key when a connected app needs one replacement, or Revoke Connection Key when it should stop without a replacement. Either action disables triggers created by the old key. Reconnect the app to create fresh triggers; events during the disconnected gap are not automatically replayed. Credential Inventory shows current and historical records but never shows the secret again.

Give each credential only the access the application needs. A credential can narrow its owner’s current access, but it cannot expand it. Ask the person building the integration to review the generated API reference before choosing permissions or making requests.

Create a webhook

Section titled “Create a webhook”

Use a webhook when FSRevs should send selected activity to another service. The webhook guide explains event scope, signing, testing, delivery health, and troubleshooting.

  1. Get the service’s production Webhook URL.
  2. Open Integrations → Webhooks and choose Create Webhook.
  3. Choose the owner and the activity, Forms, and Review Flows to include.
  4. Save the webhook and immediately copy its one-time signing secret.
  5. Send a test and confirm that the receiving service accepts it.

The owner must have API Access enabled, but FSRevs delivers webhooks without using an API credential. Give the signing secret to the trusted person or service that will verify the messages. See Create and verify webhooks for setup and troubleshooting.

For your technical partner

Section titled “For your technical partner”

Custom API integrations use your workspace-specific base URL:

https://your-workspace.fsrevs.com/api/v1

Send the complete credential as Authorization: Bearer <credential>. Operations that create or update data or send requests require an Idempotency-Key, which allows the same operation to be retried safely if its response is lost. Reusing a key with different input returns a conflict. FSRevs rechecks current access before returning a saved result. Check the reference for each operation: read-only lookups and repeat-safe deletion operations have different requirements.

The generated API reference is the source of truth for exact routes, permissions, request fields, responses, and errors.

The same contract is available as a machine-readable OpenAPI schema.

Verify the connection before sending

Section titled “Verify the connection before sending”

Call GET /api/v1/connection on your workspace host with the credential in the authorization header. A successful response identifies the authenticated workspace without creating a Customer or sending a message. Confirm that it is the workspace you intended to connect.

Then test the smallest operation your automation needs. A successful connection check confirms authentication; it does not grant access to every resource or confirm that a message can be delivered.

Confirm your first automation worked

Section titled “Confirm your first automation worked”
  1. Run one controlled example using your own test contact details.
  2. For a Customer synchronization, open Customers and confirm the intended record was created or updated.
  3. For a send, find the request in Flow Activity or Form Responses, then inspect Message History.
  4. For a trigger, create one matching new event after the trigger is connected and confirm the receiving automation ran once.

An accepted API request is not proof that a message reached the inbox or that a customer responded. If a sending action times out, inspect the existing request before starting another send. See Customer Identity and Sending.

Next steps

Section titled “Next steps”