Troubleshoot a connected integration that does not sync
If answers aren't reaching your email platform, you'll find how to check the visitor's identity, answer mappings, permissions, and failed requests.
Updated
View as MarkdownFind where an answer stopped on its way to your email platform. A connected integration can still have trouble identifying one visitor, saving a mapped answer, or creating a subscriber.
Use a fictional test contact you control. Note the page, approximate test time, provider, question, expected field value, and whether you're testing a draft or published configuration. Keep credentials out of support messages.
Answers appear in RightMessage, but the contact hasn't changed
- Check the browser's identity in the visitor debugger.
- If it's anonymous, follow your provider's identification steps.
- Open the question's sync tab for your provider, such as Sync with Kit, and check the destination and answer value.
- For a live test, make sure you've published the mapping.
- Leave debugger mode and submit the answer again on your website. The debugger blocks external writes.
- Check the contact in your provider. Then find the request in Settings > Integration > your provider > History.
RightMessage can save a response while the browser is still anonymous, the answer has no destination, or the provider rejects the update.
If an Email question shows an optional consent checkbox and the visitor leaves it unchecked, the answer can stay in Responses without identifying them or updating your email platform. That's a consent choice, not a connection failure.
The contact doesn't exist after signup
Check the Email question's Contact action or the action configured on your form. It needs to name the current integration and a valid destination. Kit requires a form or tag for new contacts. Mailchimp requires an audience.
Collecting or mapping an email answer doesn't by itself create a subscriber. The signup may have only looked up an existing contact or collected an email without a valid contact-creation action.
If you use a third-party form, check that it passes a supported identifier to the browser. Installing the snippet doesn't make it watch every form, and a signup processed on your server doesn't automatically identify the browser. See the automatic identification options.
The wrong record changes, or a duplicate appears
- Start a clean test session.
- Compare the intended provider contact ID with the record that changed.
- Check the identifying parameter and the type of value it needs in your provider guide.
The identifier may be in the wrong format, or the browser may remember another contact. A provider-specific defect can also need investigation.
Customer.io's application ID, internal cio_id, and email are different identifiers. RightMessage handles its _cio_id parameter in a provider-specific way. Don't assume every duplicate is a mapping mistake or keep creating contacts to test it. Save the intended ID, the ID that was created or updated, request details, and timestamp for support. See Connect Customer.io.
The connection says OK, but subscription fails
- Open History and expand the failed row.
- Compare Request with Error.
- For a Klaviyo list subscription, check that the private API key has
subscriptions:writepermission. - If the key is missing a required permission, replace it in Overview and save.
- Test a fresh signup. Check list membership separately from consent or subscription state.
A connection check can pass with permission to read data while your signup needs a different permission.
For OAuth providers, reconnect to the intended account or location. Authorizing a different account won't fix a destination mismatch.
A field is missing, rejected, or doesn't change
- If a new field is missing from the picker, choose Clear Cache in the connection's Overview.
- If you see Your saved destination is unchanged, use Manage connection to fix the connection instead of deleting the mapping.
- Compare the submitted value with the provider's field type and allowed choices.
- If you're submitting to a provider form, check its required fields.
An outdated field list, incompatible field type, or missing required value can prevent an update.
HubSpot's required form properties can block a form submission. If RightMessage falls back to updating the contact, check the HubSpot form event separately. An automation that depends on that event won't be satisfied by a contact update alone.
When RightMessage syncs stored input answers without a new submission, it preserves existing provider values. Submit a new answer to test an intentional update. For attribution, check the destination's Overwrite? setting.
History is empty, or the update hasn't arrived
- Check that you tested on your website with the published configuration, not only an editor preview.
- Check the browser's identity separately from its answers.
- Look for the expected operation in History. Keyword Search searches request and response payloads.
- Expand the matching row to see whether that operation succeeded.
The visitor's actions may not have triggered a provider request, the browser may still be anonymous, or the request may still be processing. Avoid repeated submissions while you investigate a pending action.
History shows recent requests, not a permanent record of every delivery. Providers don't share one retry interval or delivery deadline. Look for the update request itself, since a successful read doesn't tell you whether a write succeeded.
I still need help
If identity, mapping, publication, and permissions are correct but the update still fails, send support an example with private data removed. Include the provider, page, time, intended contact ID, action, destination, expected value, actual value, and relevant error. Leave out keys, tokens, and unrelated contact data.
After a repair or credential change, test both a fresh signup and an existing contact.