Customer Identity and Sending

When Make, Zapier, or another application sends a Review Request or Custom Form, FSRevs must determine which Customer it belongs to and exactly where to send it. These rules prevent an unattended automation from guessing.

How FSRevs finds an existing Customer

FSRevs looks for exact contact details:

• One Customer with the same email can be selected.
• One Customer with the same phone number can be selected.
• If both are supplied, they must identify the same Customer.
• If the details point to different Customers, or more than one Customer has the same detail, FSRevs reports a conflict instead of choosing one.
• A name or a similar-looking value never selects a Customer by itself.

If there is no exact match, the integration may create a Customer. For an existing Customer, supplied details can fill empty identity fields, but a one-time sending destination does not silently replace established contact information.

Keep a Customer in sync without sending

Use Make or Zapier’s Create or Update Customer action, or the matching API operation, to synchronize a Customer without creating a request or sending a message.

For an ongoing connection to a CRM or another system:

1. Use a consistent source name for that system and account.
2. Supply that system’s stable Customer record ID on every run.
3. Map the Customer details that the source controls.
4. When available, include the source record’s last-updated time to protect against an older delayed update.

FSRevs remembers the source and record ID together. Later runs can update the same Customer even if the Customer’s email or phone changes.

FSRevs standardizes the source name across the API, Zapier, and Make. For example, Main CRM and main-crm both become main-crm. Use a distinct name for each source account, keep it stable, and map each Customer’s actual record ID rather than one fixed value for every run. The API returns the standardized source name.

For one-time intake from a source that has no stable record ID, leave both source fields blank and supply an exact email or phone. FSRevs matches one Customer or creates a new one without saving an external link. A name alone is not enough.

Unlinking an external reference does not delete the Customer. Disable the automation first, remove only the intended reference, and make sure the next synchronization contains a unique email or phone before expecting it to reconnect.

Include the destination for every send

Every automated send must explicitly provide an email address, mobile number, or both. In Make or Zapier, map Customer Email, Customer Mobile Phone, or both from an earlier step.

Supplying only an email requests email. Supplying only a phone requests SMS. Supplying both requests both channels. If neither is supplied, the action stops with a validation error.

FSRevs does not fill a missing destination from the Customer’s stored contact details. This keeps an unattended automation from sending somewhere it was not explicitly told to use.

Testing a Make or Zapier sending action sends a real message. Use contact details you control while setting it up.

Why Portal sending feels different

Portal sending includes a person in the decision. Selecting a Customer prefills visible, editable recipient fields, and nothing is sent until the user reviews and submits the form. Clearing or changing a prefilled value changes what that send uses.

Prevent accidental repeats

FSRevs matches repeat protection by delivery channel and normalized destination. Email and SMS are independent: an earlier email does not by itself block an SMS, and an earlier SMS does not by itself block an email. Using a different Customer record does not bypass protection for the same destination, while a different destination is not blocked merely because it belongs to the same Customer.

Outstanding provider-backed work that is pending, claimed, or otherwise recoverable continues to block an equivalent request for as long as it remains outstanding, including beyond seven days. Submitted, successful, unknown, potentially accepted, and qualifying post-provider outcomes use the normal seven-day historical window. A confirmed pre-provider non-submission, cancellation, or definitive provider rejection permits a replacement.

Review Request protection applies across Review Flows. Custom Form protection applies only when the same Form and destination match. When an action requests both email and SMS, the initial safety decision is all-or-nothing: a conflict on either destination stops the entire action rather than sending only one channel. An automation cannot bypass this protection.

If a send times out or its result is unknown, do not create a new request automatically or blindly resend it. The original may already have been accepted. Review FSRevs activity first, then ask your technical partner to retry the original operation safely instead of starting a separate send.

For your technical partner

Customer synchronization uses POST /api/v1/customers/synchronize. A linked record is identified by the combination of the API-returned canonical source and the case-sensitive external_id. Nonempty mapped values update the Customer; omitted or blank values do not clear fields in V1.

Source names are trimmed, converted to ASCII, lowercased, and reduced to letters, numbers, and hyphens. Punctuation and whitespace become hyphens. Source input and the resulting value must each contain 1–80 characters. Two inputs that produce the same canonical source share the same namespace.

Send an Idempotency-Key with synchronization and sending requests; synchronization requires a UUID. If a response is lost, repeating the same operation with the same key returns the protected result while it remains available and current access permits it. Do not switch to a new key just to work around an unclear sending result.

Each sending request must include the destination used by the selected channel. This is the destination portion of a request, not a complete send payload; include the Location and Flow or Form fields required by the API reference:

{
    "email": "recipient@example.com",
    "phone": "+18085551212"
}

The optional timezone-qualified source_updated_at offers delayed-update protection. A strictly older timestamp returns older_update_ignored; a newer timestamp is remembered even when no Customer field changes. Equal or absent timestamps process normally. Without a stable source record, omit both identity fields and do not send source_updated_at.

The operation returns created, updated, unchanged, or older_update_ignored. It never creates a Review Request, Custom Form request, email, or SMS. External references can be listed and unlinked individually; there is no bulk-clear endpoint.

The default custom_form.completed webhook does not include answers or upload information. A trusted receiver can opt in to sensitive details, or an authenticated application can retrieve the current Custom Form request after verifying the webhook. Detailed messages never contain file contents or download links.

See the generated API reference for exact fields, validation, permissions, and error responses.

Troubleshoot a Customer match

What happened	What to check
The integration reports an ambiguous match	Check whether the supplied email and phone identify different Customers or are shared by multiple records. Correct the source data before retrying.
Several people update one Customer	Check for a fixed source record ID mapped into every run. Pause the automation before correcting the external reference.
A changed email creates an unexpected Customer	Check whether the stable source and record ID were omitted or changed. Contact matching alone cannot follow every change of address.
A blank field does not erase a saved value	Omitted and blank synchronization values do not clear existing fields. Review the Customer directly when a correction is needed.
A send is blocked even with a different Customer ID	Repeat protection also checks the destination and channel. Inspect the earlier request instead of creating more Customer records.

Creating or synchronizing a Customer does not establish permission to contact them. Review Deliverability & Consent before enabling a sending automation.