Important: do not delete or disable this mapping collection. Every OpenAI enrichment result reaches iPaaS.com through it. Without it, outbound enrichment requests still succeed but no result is ever written back to a Customer or a Product.
Summary
This collection receives every inbound notification from OpenAI and turns it into the transfer it actually describes. OpenAI sends one kind of notification — a response has completed — so all routing happens on the iPaaS.com side. The notification is recorded as a Message, the completed response is retrieved, and the routing details the integration attached to the original request identify which record and which collection the result belongs to.
The Message itself is a short-lived routing and audit record, not a copy of the enriched data.
iPaaS.com data type: Message
ID Format
Manual Sync ID Format
Enter the identifier OpenAI assigned to the enrichment response. In normal operation there is no reason to use Manual Sync on this collection; it exists for troubleshooting a specific notification.
External ID Format
The response identifier is recorded as the external ID for the Message. The same value is written to the enriched Customer or Product in its OpenAI Last Response ID custom field, which is what lets a Message be traced to the record it ultimately updated.
Deleted Record Support
Delete is not supported. Messages are transient and are discarded when they expire; nothing in OpenAI removes an iPaaS.com record.
Custom Field Support
Not applicable to this collection. The Message is a routing and audit record and carries no enrichment payload, so no custom fields are mapped on it. Custom fields returned by an enrichment are applied by the Customer or Product collection the Message dispatches.
Mapping Collection Status
Status: Enabled. No mapping filter is applied, so every inbound notification is recorded and routed.
Trigger Events: the OpenAI completed-response webhook. Manual Sync is available for troubleshooting.
Duplicate or Conflicting Mappings
None. No other collection receives OpenAI notifications.
Important: do not create a second Message collection for OpenAI. Notifications are routed to a single Message collection, and duplicating it produces unpredictable results.
Collision handling is not supported for this collection, and the Message model does not implement it.
Unmapped Field Overwrite Risk
The iPaaS.com API replaces the whole Message record on update. Details and MessageCreatedTime are not mapped and are therefore left empty. In practice this carries no consequence — a Message exists only to route one notification and expires within thirty minutes — but it is recorded here for completeness.
DetailFields, Links and RecipientUserIds are collection fields managed separately and are not affected.
Supported Child Collections
None. This is a standalone collection with no child collections. The Customer and Product collections it dispatches are separate top-level collections, not children of this one.
System Caveats
OpenAI Caveats
One event type carries everything. OpenAI reports completed responses through a single webhook event. There is no separate Customer or Product event.
Notification timing is OpenAI's. Enrichments complete in the background and the notification arrives when OpenAI is finished. There is no guaranteed interval.
The signing secret is not used. OpenAI issues a signing secret when the webhook is created. At the time this documentation was written the integration authenticates using the token embedded in the webhook address rather than that secret. Keep the secret safe, but no iPaaS.com setting consumes it.
iPaaS.com Caveats
A notification without routing details is skipped, not failed. If the completed response does not carry the details the integration attached when the request was made, the notification is recorded and processing stops without raising an error. This is deliberate — it is how notifications generated outside this integration are ignored — but it means a missing enrichment will not always produce an error entry.
Messages are transient. A Message expires thirty minutes after receipt and is not a permanent record of enrichment history. The durable audit trail lives on the enriched Customer or Product.
The downstream collection must be enabled. A notification for a Customer enrichment cannot be applied if the Customer TO collection is disabled, and likewise for Products.
Setup Requirements
OpenAI Configuration
The webhook is created in the OpenAI console, not from iPaaS.com. The subscriber applies the subscription settings, refreshes to reveal the Webhook API Key, URL-encodes it, and builds the webhook address from it before subscribing to the completed-response event. The full procedure, including the encoding step, is in the OpenAI Installation Instructions.
iPaaS.com Configuration
No subscriber-facing iPaaS.com-side webhook configuration is required — the receiver is part of the subscription. The downstream Customer TO and Product TO collections must be enabled for the data types in use.
Integration Flow
OpenAI reports that an enrichment response has completed.
iPaaS.com authenticates the notification using the webhook token in the address OpenAI was configured with.
A Message record is created, stamped with a severity of Info, a type of Transfer, a readable summary line, and an expiry thirty minutes ahead.
The integration retrieves the completed response from OpenAI and reads the routing details returned with it.
If those details are present, the matching Customer or Product transfer is dispatched and the enriched values are applied by that collection.
If those details are absent, the notification is recorded and skipped without raising an error.
If the dispatched transfer fails, this collection reports a prerequisite failure and the enrichment is not applied.
Mappings
Add/Update OpenAI Message TO iPaaS.com
iPaaS.com data type: Message
Mapping Type | Source Field (OpenAI) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| ExpirationTime | Required. Sets when the Message is treated as stale, thirty minutes after the webhook is received. A Message not processed within that window is discarded. The window can be lengthened by editing the number of minutes; shortening it is not recommended. |
Static |
| Severity | Required. Classifies the Message as routine activity. Allowed values are Verbose, Info, Warning, Error, None and Critical. This is a fixed system value, not an example. |
Static |
| Type | Required. Marks the Message as carrying data to be translated into another record type, which is what causes the onward dispatch. Allowed values are Transfer, Event, Billing Notification and System Status. Changing it stops inbound enrichment from being applied. |
Dynamic Formula |
| Text | Recommended. Builds a short readable line combining the scope the webhook was received under with the identifier OpenAI assigned to the response. The quickest way to confirm OpenAI is calling iPaaS.com when an enrichment appears not to have completed. |
Error Handling
Errors on this flow are cataloged in the OpenAI Error Messages article. The one specific to this collection is:
"Error during prerequisite action for MESSAGE during proper hook creation. This will prevent further processing of the transfer request.": the notification was received and its routing details were read, but the Customer or Product transfer it dispatched did not complete. The underlying failure is logged separately and is usually the more useful entry to read.
Errors returned by OpenAI when the completed response is fetched are documented in the same article.
Testing & Validation
Test Scenarios
Submit a record for enrichment and confirm a Message is created when OpenAI completes, with the expected severity, type and summary line.
Confirm the Message dispatches the correct downstream transfer for the data type that was enriched.
Disable the downstream Customer TO collection, submit an enrichment, and confirm the prerequisite failure is reported.
Allow a Message to expire without being processed and confirm the enrichment is not applied afterwards.
Confirm the response identifier on the Message matches the OpenAI Last Response ID written to the enriched record, so the two can be correlated.
Send a notification that carries no routing details and confirm it is recorded and skipped without an error.
Validation Checklist
This collection is enabled and its four mappings are unmodified.
The webhook address in the OpenAI console is correctly URL-encoded and points at this subscription.
The completed-response event is selected in the OpenAI console.
The downstream Customer TO and Product TO collections are enabled for the data types in use.
The expiry window is appropriate for the expected enrichment turnaround.
Additional Notes
This collection is a single point of dependency: every enrichment result for every data type passes through it, which is why it ships with an explicit do-not-delete warning.
Because a notification lacking routing details produces no error, an enrichment that never arrives may need to be diagnosed from Message activity rather than from the error log.
Bulk initialization and polling are not supported. This collection is driven entirely by inbound notifications.