Most transfers are a straightforward create or update. This article covers the cases that need more: sequencing a transfer against data it depends on, breaking bidirectional loops, and where to find the platform's handling for the other concerns that come up during a build.
Prerequisites and post-actions
Sometimes a record cannot transfer on its own. It may depend on other data existing first, or it may require follow-up work once the main record is saved.
Prerequisites run before the main transfer to make sure a dependency exists. A common case: an order webhook arrives before the customer webhook. A prerequisite transfers the customer first so the order can link to it instead of failing.
Post-actions run after the main transfer to complete related follow-up work, such as creating a deposit ticket or gift card record that accompanies a completed transaction.
Both are handled in TranslationUtilities via HandlePrerequisite and HandlePostActions, which run through DataHandlerFunctionAsync. These calls do not throw on failure, so check the HasErrors field after the call to find out whether an error occurred. If the failure is fatal to your transfer, throw an exception that includes the id and type of the data that failed, so the log is actionable. See Advanced Error Handling & Logging for the exception detail.
Identify prerequisite and post-handling events during discovery, before you build. See Discovery and Planning.
Bidirectional flows and clapback prevention
When data flows both directions between iPaaS.com and an external system, an update you send out can trigger a webhook back to iPaaS.com, which then tries to reprocess the same data you just wrote. That circular loop is a clapback. Prevent it by registering outgoing calls with the clapback tracker using RegisterClapbackCall in TranslationUtilities:
Update calls: register the clapback before making the update.
Create calls: you do not have an external ID yet, so register the clapback immediately after the create completes and you have the new ID.
Registration tells iPaaS.com to ignore incoming webhooks for that specific record within a short time window, which breaks the loop.
Special considerations index
The other advanced concerns each have a dedicated home. Use this as the map:
Collision handling (duplicate detection and linking): Handling Duplicate Records
External IDs, ParentOnly mappings, and child linking: Managing External IDs
Control fields, JsonIgnore, embedded collections, and CRUD behavior: Data Modeling
Rate limits and throttling (QuotaException, SleepWithCancelSupport): Working with API Rate Limits
Logging, exceptions, 404 handling, batch processing, pagination, caching, and token re-authorization: Advanced Error Handling & Logging
Delete Triggered Updates and transformation logic: Data Mapping and Custom Transformation Functions
Declaring which flows, webhooks, and polling an integration supports: Supported Features Format