Verify a new connection or replacement API key

Check that new leads reach your email platform and existing contacts get the answers they submit. This is worth doing after you connect a platform, replace an API key, reconnect, or change an answer mapping.

Get two test contacts ready

Use contacts you control, not customer records. You'll need permission to edit the project, access to contact records in your email platform, and a page on your website running the RightMessage snippet.

Choose one email address that isn't in your platform yet and one existing test contact. Note the existing contact's ID and current field values. If your provider sends confirmation emails, use deliverable addresses on a domain you control. Use its testing controls to keep unrelated email automations from running for these contacts.

Make the submissions on your actual website. A dashboard preview doesn't send the full live contact submission.

Check your connection and mappings

1. Open Integrations and choose your provider.
2. If you're replacing an API key, enter it on Overview and choose Save Changes. For OAuth, use Reconnect to, followed by your provider's name.
3. Fill in any additional details your platform needs, such as Drip's Account ID or Salesforce/Pardot's Business Unit ID.
4. Check the connection status and address any error.
5. Open your question's sync tab, labeled with your provider, such as Sync with Kit. Check the destination and saved value for your test answer.
6. Inspect the Email question's contact action or the form action. Confirm the intended list, form, or tag destination.
7. Review the project's full set of changes, then publish the intended mappings and flow changes.

Enlarge

Question sync destination and mappings from team answers to Acme CRM custom-field valuesOriginalOriginal

Test a fresh signup

1. Open a fresh private browser window on your actual page.
2. Follow the normal visitor path without forcing a segment or bypassing targeting.
3. Submit an answer you can recognize in the contact record. For example, WorkForge (opens in a new tab) could test the remote value for its work-style question.
4. Submit the new test email through the configured signup path. Supply consent if your question requests it.
5. Open the provider and find the new contact.
6. Check the contact's email, mapped answer, and intended list, form, or tag membership.
7. If your provider uses double opt-in, complete that confirmation and inspect the resulting subscription state separately.

Check the values in the contact record even if your website showed a success message. Your platform may handle the contact update and subscription separately.

Test an existing contact

1. Start another clean browser session.
2. Open an identifying email link sent to your existing test contact, or use another identification method your provider supports.
3. Use the visitor debugger to check that RightMessage recognizes the contact.
4. Leave the debugger and reopen the identifying link on your live page without debugger mode. Submit a different mapped answer.
5. Find the original contact by the ID you noted earlier.
6. Check that the same record changed, without creating a duplicate or shadow contact.
7. Revisit as that identified contact and check that the saved choice matches the expected segment.

The debugger blocks external writes. Use it to check identity and what RightMessage chooses to show, then leave it for the live submission.

If your plan includes visitor profiles, the connected-provider Data tab is another place to inspect contact data. Check the destination record in your platform too.

Keep a note of what happened

Note the test page, approximate time, provider, contact ID, question, destination, expected value, and saved value. Don't include credentials. These details give you something to compare if the update stops working later.

If an action fails, open History on the integration page and expand its request. Check the response or error. Permission to read contacts doesn't always include permission to subscribe them. Klaviyo list subscriptions, for example, need the relevant write scope.

There's no universal wait or retry interval. Check the request's status rather than submitting repeatedly and risking duplicate actions.

When a new contact receives the expected data and the existing contact updates without a duplicate, the connection is working for those actions. If either check fails, use contact-sync troubleshooting to find whether identity, mappings, permissions, or your platform's requirements caused it.