Summary
iPaaS.com Customers can be sent to OpenAI for enrichment through Manual Sync or outbound triggers. Each transfer assembles the mapped Customer fields into a JSON record, pairs it with the instruction held in the PromptText mapping, and submits it to OpenAI. OpenAI completes the work in the background and returns the enriched Customer separately, through the OpenAI to iPaaS.com Message Mapping Documentation and OpenAI to iPaaS.com Customer Mapping Documentation flows.
iPaaS.com data type: Customer
ID Format
Manual Sync ID Format
Enter the iPaaS.com Customer Id on the Manual Sync page. Manual Sync from iPaaS.com always takes an iPaaS.com record id, which is numeric.
External ID Format
The value mapped to the Id destination is what OpenAI records against the enrichment request, and it is what allows the returned result to be matched back to the originating Customer. The default mappings supply the Customer Number.
After the round trip completes, the identifier OpenAI assigned to its response is recorded against the Customer and is also written to the OpenAI Last Response ID custom field, where it is visible on the record.
Deleted Record Support
Outbound delete is not supported. The Customer model's delete operation is not implemented, delete mappings are not included in the default templates, and removing a Customer in iPaaS.com does not remove anything in OpenAI.
Custom Field Support
Custom fields are how the enrichment returns anything that does not fit an existing Customer field.
An instruction can ask OpenAI to produce a named custom field, and the shipped example does exactly that — a Known To Film value. Returned values are matched to iPaaS.com custom fields by name, so the name used in the instruction and the name of the custom field must agree exactly.
Two rules govern this:
A custom field that is already the destination of a mapping arrives with the integration template and needs no manual setup.
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 in OpenAI to iPaaS.com Customer Mapping Documentation first.
Mapping Collection Status
Status: Enabled. No mapping filter is applied, so every Customer submitted to this collection is sent to OpenAI.
Trigger Events: Manual Sync, plus the iPaaS.com customer/created and customer/updated outbound triggers once they are subscribed to this collection under Outbound Data Flows.
Duplicate or Conflicting Mappings
OpenAI to iPaaS.com Customer Mapping Documentation operates on the same iPaaS.com Customer entity. It is the return 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 risk sits on the return leg, not here: this collection only reads from iPaaS.com. See the corresponding section of OpenAI to iPaaS.com Customer Mapping Documentation, which identifies the Customer field cleared on every inbound write unless a mapping is added to preserve it.
Cross-integration risk. Under the shipped example instruction the Comment field is overwritten on every transfer. Confirm that no other integration is treated as the source of truth for the fields the instruction is allowed to change.
Supported Child Collections
None. This is a standalone collection with no child collections. Customer addresses, relationships and category assignments are not part of this transfer.
System Caveats
OpenAI Caveats
Processing is asynchronous. A request is accepted and completed in the background. The enriched result is not available when the outbound transfer finishes; it arrives later. Timing depends on OpenAI.
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 and no data is lost.
Usage and quota. Enrichment consumes OpenAI account usage on every transfer, and the volume follows how many Customers are subscribed to automatic transfer. Quota and billing tiers are managed in the OpenAI account.
Output is not deterministic. The same Customer submitted twice with the same instruction can produce different wording. Write instructions so any acceptable answer is usable.
iPaaS.com Caveats
The return leg must be configured. Results are only applied if the Message and Customer TO collections are enabled and the OpenAI webhook has been created. Without them the outbound request succeeds and nothing is written back.
Required Customer values must survive the round trip. iPaaS.com requires a Customer Number and a unique email address, and at least one of first name, last name or company. Those values originate here, so unmapping them breaks the inbound write.
Categories are never modified. The integration instructs OpenAI to leave category assignments alone, so an instruction asking for category changes has no effect.
Data leaves iPaaS.com. Every mapped field is transmitted to OpenAI, including names, email addresses and comments. Confirm this is consistent with your organisation's data-handling policy, and unmap any field that should not be sent.
Setup Requirements
OpenAI Configuration
An OpenAI account with an API key carrying at least Write permission on the Responses capability, and a webhook created in the OpenAI console pointed at the subscription's webhook address so results can be returned. iPaaS.com does not register that webhook — the subscriber creates it. The full procedure is in the OpenAI Installation Instructions.
iPaaS.com Configuration
The subscription's API Url, API Key and OpenAI Model settings completed and applied. For automatic transfers, subscribe the customer/created and customer/updated triggers to this collection under Outbound Data Flows. Until those subscriptions are enabled, enrichment runs only through Manual Sync. See the OpenAI Connections and Settings article.
Integration Flow
A Customer is created or updated in iPaaS.com, or a Manual Sync is triggered for a Customer Id.
The mapped Customer fields are assembled into a JSON record.
The instruction in PromptText is combined with that record to form the request.
The request is submitted to OpenAI with background processing enabled, carrying routing details that identify the Customer and its collection.
OpenAI accepts the request and the outbound transfer completes. No enriched data is available yet.
OpenAI finishes the work and notifies iPaaS.com.
The notification is received as a Message, which reads the routing details and dispatches the inbound Customer transfer.
The enriched values are written to the Customer by OpenAI to iPaaS.com Customer Mapping Documentation.
Mappings
Add/Update OpenAI Customer FROM iPaaS.com
iPaaS.com data type: Customer
Mapping Type | Source Field (iPaaS.com) | Destination Field (OpenAI) | Description |
Field | CustomerNumber | Id | Required. Carries the Customer Number across as the identifier OpenAI records against the request. The transfer stops with an error before any request is sent if this is not mapped. |
Static | (see PromptText Example below) | PromptText | Required. The instruction OpenAI follows. Governs everything the enrichment produces. Ships with a demonstration value that must be replaced before go-live. |
Field | CustomerNumber | CustomerNumber | Recommended. Lets the model refer to the customer by their business identifier and returns it unchanged. |
Field | FirstName | FirstName | Recommended. Naming context for the instruction. |
Field | LastName | LastName | Recommended. Naming context for the instruction. |
Field | EmailAddress | EmailAddress | Recommended. iPaaS.com requires an email address on a Customer, so the value must survive the round trip for the inbound write to succeed. |
Field | Comment | Comment | Recommended. Carries the existing comment across so the model can see what is already recorded. Under the shipped instruction this is also where the generated summary is returned, replacing the previous comment. |
Field | Categories | Categories | Optional. Supplies category context only. Category changes are never applied, so an instruction asking for them has no effect. |
PromptText Example
The instruction below is the value this collection ships with. It is a demonstration, not a business rule — the profile summary, the imdb.com lookup and the Known To Film field name are all example choices. Replace it with an instruction describing the enrichment you actually want, and remove or repoint the corresponding custom field mapping on the return leg if the new instruction does not produce that value.
Write a short, bulleted summary of this customer profile and return it in the comment field. Check whether this customer is known by imdb.com. Return TRUE or FALSE in custom field named Known To Film.
Error Handling
Errors on this flow are cataloged in the OpenAI Error Messages article. The two raised by this collection before any request reaches OpenAI are:
"The destination field {{id}} must be present and defined in your FROM iPaaS.com data mappings. Please correct this and try again.": no mapping writes to the Id destination. Add a Field mapping with CustomerNumber as the source and Id as the destination.
"The user defined Model Instructions could not be parsed as valid JSON. Please correct the issue and try again. Error Details: …": the optional ModelInstructions mapping holds content that is not valid JSON. Correct it or remove the mapping.
Errors returned by OpenAI itself, and connection failures, are documented in the same article.
Testing & Validation
Test Scenarios
Manual Sync a Customer with a complete record and confirm the outbound transfer succeeds and an enrichment request is accepted by OpenAI.
Confirm the enriched Comment arrives on the Customer after OpenAI completes, via the return leg.
Remove the Id mapping, attempt a transfer, and confirm the expected error is raised before any request is sent.
Set ModelInstructions to malformed JSON, attempt a transfer, and confirm the parsing error is raised.
Subscribe the customer/created and customer/updated triggers, update a Customer, and confirm an automatic transfer fires.
Replace the shipped PromptText with a business-specific instruction and confirm the returned values land in the intended fields.
Ask the instruction to produce a custom field that has no mapping, and confirm the value is discarded.
Validation Checklist
The Id mapping is present and sourced from a value that uniquely identifies the Customer.
PromptText has been replaced with a business-specific instruction.
Every custom field the instruction names exists in iPaaS.com and is mapped on the return leg.
EmailAddress stays mapped on both legs, since iPaaS.com requires it on the inbound write.
The OpenAI webhook has been created and points at this subscription.
The Message and Customer TO collections are enabled.
Additional Notes
Enrichment consumes OpenAI usage per record. Consider adding a mapping filter to restrict which Customers are submitted before enabling automatic transfers.
Bulk initialization is not supported. To enrich an existing population, use bulk sync using Postman.
Polling is not supported; transfers occur by outbound trigger or Manual Sync.