Contact Update and Pond Rotation Fixes

What We Fixed

• A contact moved by a rotation now starts its waiting period in the new pond. Previously it kept its original timestamp, so in a chain of rotations it immediately qualified for the next one and could travel several ponds in a single run.
• A contact is moved at most once per rotation run.
• A rotation can no longer be set up — or switched back on — to move contacts into another team’s pond, and an existing rotation configured that way is now skipped instead of running.
• Rotation loops are caught when you save, however many ponds they span. Previously only a direct two-pond loop was detected, so a longer chain that circled back — say New Leads → Follow-up → Nurture → New Leads — could be saved and would keep moving contacts around the loop.

What Changed for Integrations

• Contact payloads now include assignedPondId and assignedGroupId. These are additive; every existing field is unchanged.
• Fewer duplicate notifications. Updating a contact together with its emails, phones or addresses in a single API call now sends one peopleUpdated notification instead of one per record changed. The payload is unchanged and reflects the final state.
• Phone validation no longer sends its own notification. When a phone number finishes validating — or its Do Not Call status is checked — that no longer emits a separate peopleUpdated. The payload was identical to the one already sent when the number was added, so no information is lost — but automations counting events will see fewer.