These are the known limitations of the OpenAI integration. They are inherent to the current design of the integration and to the capabilities of the OpenAI API, and they apply to all subscribers at the time this documentation was written.

The integration is built for OpenAI, the commercial API offered by OpenAI at https://platform.openai.com.

Not built for. This integration targets the OpenAI Responses API only. It is not built for, and cannot be pointed at:

If OpenAI launches a separate product line or a materially different API surface in the future, this integration will not automatically support it.

The integration does not offer a bulk import that enriches an existing population in one operation. Records are submitted individually, by Manual Sync or by an outbound trigger.

What this means for you. To enrich a catalogue or customer base that already exists, use bulk sync using Postman, which drives the same transfers the integration uses for individual records. Size the run deliberately — enrichment consumes OpenAI account usage on every record.

The integration does not poll OpenAI on a schedule. Nothing is retrieved unless a record was first submitted for enrichment.

What this means for you. Transfers happen when you trigger them, either through Manual Sync or through the outbound triggers you subscribe under Outbound Data Flows. This is the right shape for the integration: OpenAI holds no records of its own to discover, only responses to requests you made.

Removing a Customer or Product in iPaaS.com does not remove anything in OpenAI, and nothing in OpenAI removes an iPaaS.com record. Delete mappings are not included in the default templates.

What this means for you. Enrichment is a one-way enhancement of your own records. Manage record lifecycle in iPaaS.com as you normally would; there is no cleanup step on the OpenAI side.

Each entity is served by a pair of collections — one that sends the record to OpenAI, one that applies the result. The inbound collection retrieves a response by its identifier, and that response only exists if the outbound transfer created it.

What this means for you. Manual Sync on an inbound collection cannot enrich a record that was never submitted. Always start from the outbound side. Both collections in a pair, plus the Message collection, must be enabled for a working round trip.

OpenAI completes enrichment in the background and notifies iPaaS.com when it is finished. The enriched values are not available at the moment the outbound transfer completes.

What this means for you. Allow time between submitting a record and seeing the enriched values on it. At the time this documentation was written there is no progress indicator for a request in flight, so a transfer that has completed successfully but not yet produced values is expected behaviour rather than a failure.

Each inbound notification is recorded as a Message that expires thirty minutes after it is received. Separately, because enrichment requests are submitted without long-term storage, OpenAI retains the completed response only briefly to support background processing.

What this means for you. In normal operation neither window is reached. If a result is not applied — for example because a downstream collection was disabled, or processing was delayed — the enrichment is lost and the record has to be submitted again. Confirm that both collections in a pair are enabled before submitting a large batch, so results are not being produced faster than they can be consumed.

iPaaS.com replaces the whole record when it is updated. Any field that is not mapped on an inbound collection is written as empty each time an enrichment result is applied.

On Add/Update OpenAI Product TO iPaaS.com the affected fields are AllowBackorders, AllowDiscounts, Barcode, InStockThreshold, MSRP, SalePrice, TaxClass and Unit. On Update OpenAI Customer TO iPaaS.com the affected field is Company.

What this means for you. This is the most important item on this page to resolve before go-live. Several of the Product fields carry commercial data, and losing them silently on every enrichment is a real risk on a live catalogue. For any of these fields that you populate from another source, add a Dynamic Formula mapping using the DestinationValue function to carry the existing value forward — for example DestinationValue.SalePrice mapped to the SalePrice destination. Category assignments, addresses, variants, inventory and related records are managed separately and are not affected.

Submitting the same record twice with the same instruction can produce different wording. This is how language models behave, not a fault in the integration.

What this means for you. Write instructions so that any acceptable answer is usable, rather than expecting a specific string. If you need a value to be stable — a code, a flag, a category — constrain it in the instruction to a small set of allowed answers, and validate it in a staging environment before relying on it.

When OpenAI returns a result, the mapped fields are written to the live record. There is no approval stage between the model producing a value and iPaaS.com storing it.

What this means for you. Validate every instruction thoroughly in a staging environment before enabling automatic transfers in production, and be deliberate about which destination fields an instruction is allowed to change. Restricting the mapped fields on an inbound collection is the simplest way to bound what an enrichment can affect. If your workflow needs an approval stage, submit a feature request to your iPaaS.com partner channel describing the review step you need — input like this informs future enhancement releases.

The integration instructs OpenAI to leave category assignments alone. Categories are sent as context so the model can use them, but any change it proposes is ignored.

What this means for you. Categories remain under the control of whatever system owns them. An instruction that asks for category changes has no effect, so use a custom field instead if you want the model's opinion recorded.

An instruction can ask OpenAI to produce a named custom field. The returned value is matched to an iPaaS.com custom field by name. Custom fields that are already the destination of a mapping arrive with the integration template, but a custom field named only inside the instruction is not created automatically.

What this means for you. If you extend an instruction to produce a new custom field, add that custom field in iPaaS.com and map it on the inbound collection first. Otherwise the model returns the value and it is discarded silently. Check the spelling matches exactly — the match is by name.

Where an instruction asks the model to supply information it was not given — the shipped Product example asks it to research width, height, depth and weight from public sources — the values returned are its best inference, not verified data.

What this means for you. Treat researched values as provisional. If you use dimensional data for shipping, rating or compliance, confirm the figures before relying on them, or leave those fields unmapped on the inbound collection so they are never overwritten. The OpenAI Dimension Explanation custom field records where the model believes each value came from, which makes the basis reviewable.

iPaaS.com does not register the webhook that returns enrichment results. The subscriber creates it in the OpenAI console, pointed at the subscription's webhook address.

What this means for you. Until that webhook exists, outbound transfers succeed and no result ever comes back. The full procedure, including the URL-encoding step, is in the OpenAI Installation Instructions. If enrichment appears to run but nothing returns, this is the first thing to check.

Every inbound notification is checked for the routing details the integration attached to the original request. A notification that does not carry them is recorded and skipped without raising an error. This is deliberate — it is how notifications produced outside this integration are ignored.

What this means for you. A missing enrichment will not always produce an entry in the error log. If a result never arrives, review Message activity to confirm whether OpenAI called iPaaS.com at all before treating it as an error.

The integration does not provide configurable collision handling or record-matching options on any collection.

What this means for you. Records are matched by the external-ID link iPaaS.com maintains, with the primary identifier field acting as a fallback when no link exists yet. There are no matching rules to configure, and no conflict-resolution options to select.

The integration ships with example values that demonstrate what enrichment can do. They are not business rules, and each should be reviewed before the integration is used in production.

This document covers fifteen known limitations. For detailed technical documentation of how each mapping collection behaves, see the mapping collection descriptions in the iPaaS.com mapping configuration pages and the per-collection articles in the OpenAI Mapping Collections section of the Help Center.