Summary

A completed OpenAI enrichment is applied back to the iPaaS.com Customer it came from through this collection. It is the return leg of OpenAI from iPaaS.com Customer Mapping Documentation: the notification OpenAI sends is received as a Message, the completed response is retrieved, and the mapped fields are written onto the Customer along with an audit trail of which request produced them.

iPaaS.com data type: Customer

ID Format

Manual Sync ID Format

Enter the identifier OpenAI assigned to the enrichment response. This is the same value stored on the Customer in the OpenAI Last Response ID custom field after a successful transfer, so the simplest way to re-run one is to copy it from the record.

Manual Sync on this collection can only retrieve a response that already exists, which means the Customer must previously have been sent through OpenAI from iPaaS.com Customer Mapping Documentation.

External ID Format

iPaaS.com records the link between the two systems on a dedicated external-ID record, and that record is the primary match routing subsequent transfers for a Customer that has already been synchronised.

The default mappings additionally write the source identifier into CustomerNumber. That gives visibility on the Customer record and serves as a fallback match when no external-ID record exists yet — iPaaS.com then links to the existing Customer rather than creating a duplicate. Remapping CustomerNumber to a different source is supported, but it disables that fallback for Customers that already exist.

Deleted Record Support

Delete is not supported. The Customer model's delete operation is not implemented and nothing in OpenAI removes an iPaaS.com Customer.

Custom Field Support

Four of this collection's nine mappings write to custom fields.

OpenAI Last Response ID, OpenAI Last Prompt Text and OpenAI Last Response Date are supplied by the integration itself on every inbound transfer and together give a complete audit trail of the most recent enrichment. Known To Film is different — it holds a value the model was asked to produce by the instruction configured on the outbound collection, and is matched from the response by name.

Two rules govern custom fields an instruction asks for:

A custom field that is already the destination of a mapping arrives with the integration template and needs no manual setup. All four above fall into this group.
A custom field named only inside the instruction, with no mapping of its own, is not created for you and its value is discarded. Add it in iPaaS.com and map it here first.

Mapping Collection Status

Status: Enabled. No mapping filter is applied, so every enrichment result routed here is written to the Customer.
Trigger Events: the OpenAI completed-response webhook, dispatched via the Message collection. Manual Sync is also available.

Duplicate or Conflicting Mappings

OpenAI from iPaaS.com Customer Mapping Documentation operates on the same iPaaS.com Customer entity. It is the outbound leg of this collection rather than a competitor, and the two are designed to run as a pair.

Collision handling is not supported for this collection, and the Customer model does not implement it.

Unmapped Field Overwrite Risk

The iPaaS.com API replaces the whole Customer record on update. The following Customer field is not mapped in the default template mappings, so any existing value it holds is overwritten with an empty value each time an enrichment result is applied, unless a mapping is added to preserve it:

Company

Where Company is populated from another source, add a Dynamic Formula mapping that carries the existing iPaaS.com value forward. The DestinationValue function does this: mapping DestinationValue.Company to the Company destination preserves whatever the Customer already holds instead of clearing it.

Note that Company also participates in an iPaaS.com requirement — a Customer must carry at least one of first name, last name or company. This collection maps the first two, so the requirement is satisfied without Company, but clearing it silently is still a data loss.

Category assignments and address records are not affected — they are managed separately and are not cleared by this transfer.

Cross-integration risk

Because this collection applies whatever the model returned, it should not be enabled on fields where another system is the agreed source of truth.

Supported Child Collections

None. This is a standalone collection with no child collections.

System Caveats

OpenAI Caveats

Only a completed response can be read. A response that has not finished, or that OpenAI no longer holds, cannot be applied.
Rate limiting. When OpenAI reports its request rate has been exceeded, the transfer is rescheduled automatically and resumes once the limit window has passed. No action is required.
The response shape depends on the instruction. This collection can only write fields the model actually returned. A field the instruction never mentioned comes back unchanged from what was sent out.

iPaaS.com Caveats

The outbound leg must have run first. There is no enrichment result to apply for a Customer that was never submitted.
Required Customer values must be present. iPaaS.com rejects the write if Customer Number or Email Address is missing, if the email address duplicates another Customer, or if none of first name, last name or company is supplied. Because these values originate from the outbound transfer, they must stay mapped on both legs.
Categories are never modified. The integration instructs OpenAI to leave category assignments alone.

Setup Requirements

OpenAI Configuration

A webhook created in the OpenAI console pointed at the subscription's webhook address and subscribed to the completed-response event. iPaaS.com does not register it — the subscriber creates it. The full procedure is in the OpenAI Installation Instructions.

iPaaS.com Configuration

OpenAI to iPaaS.com Message Mapping Documentation enabled, since every enrichment result is routed through it, and OpenAI from iPaaS.com Customer Mapping Documentation configured, since this collection has nothing to apply without it. No additional iPaaS.com-side webhook configuration is required.

Integration Flow

OpenAI finishes an enrichment and notifies iPaaS.com.
The notification is received as a Message and authenticated using the token in the webhook address.
The Message collection retrieves the completed response and reads the routing details attached to the original request.
Those details identify the Customer and this collection, and a transfer is dispatched here.
The enriched Customer is read out of the response.
The mapped fields are written to the iPaaS.com Customer, replacing the whole record.
The audit custom fields are stamped with the response identifier, the instruction used, and the time.

Mappings

Update OpenAI Customer TO iPaaS.com