Skip to main content

OpenAI from iPaaS.com Product Mapping Documentation

How iPaaS.com Products are sent to OpenAI for enrichment: the field mappings, the instruction that drives the result, and how the enriched Product returns.

Summary

iPaaS.com Products can be sent to OpenAI for enrichment through Manual Sync or outbound triggers. Each transfer assembles the mapped Product 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 Product separately, through the OpenAI to iPaaS.com Message Mapping Documentation and OpenAI to iPaaS.com Product Mapping Documentation flows.

iPaaS.com data type: Product

ID Format

Manual Sync ID Format

Enter the iPaaS.com Product Id on the Manual Sync page. Manual Sync from iPaaS.com always takes an iPaaS.com record id, which is numeric.

Example: 12345

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 Product. The default mappings supply the SKU.

After the round trip completes, the identifier OpenAI assigned to its response is recorded against the Product 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 Product model's delete operation is not implemented, delete mappings are not included in the default templates, and removing a Product 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 Product field.

An instruction can ask OpenAI to produce a named custom field, and the shipped example does this twice — an OpenAI Response Season value recording which season the description was themed for, and an OpenAI Dimension Explanation value describing where the researched dimensions came from. 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 the custom field in iPaaS.com and map it in OpenAI to iPaaS.com Product Mapping Documentation first.

Mapping Collection Status

  • Status: Enabled. No mapping filter is applied, so every Product submitted to this collection is sent to OpenAI.

  • Trigger Events: Manual Sync, plus the iPaaS.com product/created and product/updated outbound triggers once they are subscribed to this collection under Outbound Data Flows.

Duplicate or Conflicting Mappings

OpenAI to iPaaS.com Product Mapping Documentation operates on the same iPaaS.com Product 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 Product 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 Product Mapping Documentation, which lists the eight Product fields cleared on every inbound write unless mappings are added to preserve them.

Cross-integration risk. The enrichment writes back to live Product fields. Under the shipped example instruction the Description field and the four dimension fields are overwritten on every transfer. Confirm that no merchandising or PIM system is treated as the source of truth for those same fields before enabling automatic transfers.

Supported Child Collections

None. This is a standalone collection with no child collections. Product variants, inventory, categories, options and related products 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. On a large catalogue with automatic transfers enabled this can be substantial. Quota and billing tiers are managed in the OpenAI account.

  • Output is not deterministic. The same Product submitted twice with the same instruction can produce different copy. Write instructions so any acceptable answer is usable.

  • Researched values are inferences. Where an instruction asks the model to supply attributes it was not given — as the shipped example does for the four dimensions — the values are its best inference from public sources, not verified product data.

iPaaS.com Caveats

  • The return leg must be configured. Results are only applied if the Message and Product TO collections are enabled and the OpenAI webhook has been created. Without them the outbound request succeeds and nothing is written back.

  • Required Product values must survive the round trip. iPaaS.com rejects a Product write missing Sku, Name, Type, TrackingMethod, DefaultPrice or Status, or carrying a value outside the allowed set for Type, TrackingMethod or Status.

  • 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 pricing. Unmap any field that should not be sent to an external service.

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 product/created and product/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

  1. A Product is created or updated in iPaaS.com, or a Manual Sync is triggered for a Product Id.

  2. The mapped Product fields are assembled into a JSON record.

  3. The instruction in PromptText is combined with that record to form the request.

  4. The request is submitted to OpenAI with background processing enabled, carrying routing details that identify the Product and its collection.

  5. OpenAI accepts the request and the outbound transfer completes. No enriched data is available yet.

  6. OpenAI finishes the work and notifies iPaaS.com.

  7. The notification is received as a Message, which reads the routing details and dispatches the inbound Product transfer.

  8. The enriched values are written to the Product by OpenAI to iPaaS.com Product Mapping Documentation.

Mappings

Add/Update OpenAI Product FROM iPaaS.com

iPaaS.com data type: Product

This collection sends Product data to OpenAI for enrichment. The instruction in PromptText governs what the model produces; every other mapping supplies either the identifier OpenAI correlates on or context the model can reason about.

Mapping Type

Source Field (iPaaS.com)

Destination Field (OpenAI)

Description

Field

Sku

Id

Required. Carries the SKU 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

Sku

Sku

Required. Identifies the product to the model by catalogue identifier. The shipped instruction uses it to research dimensions.

Field

Name

Name

Required. Primary context for descriptive instructions. iPaaS.com requires a name on a Product, so it must survive the round trip.

Field

Description

Description

Recommended. Carries the existing description across so the model can see what is already written. Under the shipped instruction this is also where the rewritten description is returned.

Field

Type

Type

Required. Allowed values are Physical and Virtual.

Field

TrackingMethod

TrackingMethod

Required. Allowed values are Product and Variant.

Field

DefaultPrice

DefaultPrice

Required. Context for pitching generated copy at the right market position.

Field

Status

Status

Required. Allowed values are Preorder, Active, Disabled and Discontinued.

Field

Width

Width

Optional. Shows the model which dimension is already recorded before it is asked to supply one.

Field

Height

Height

Optional. Behaves as Width does.

Field

Depth

Depth

Optional. Behaves as Width does.

Field

Weight

Weight

Optional. Behaves as Width does. Most often consumed downstream by shipping calculations, so confirm any model-supplied figure.

PromptText Example

The instruction below is the value this collection ships with. It is a demonstration, not a business rule — its audience, seasonal theme, hundred-character limit and two custom field names are all example choices. Replace it with an instruction describing the enrichment you actually want, and remove or repoint the corresponding custom field mappings on the return leg if the new instruction does not produce those values.

Write a customer facing description tailored to appeal to Adult Men between ages 35-50. Theme the description for the current calendar season and make it cheery.

The default description will be found in the field:description, but also include helpful information from custom_fields and categories.category_names.

The new description should be less than 100 characters.

Create a custom field named "OpenAI Response Season" and add the Season that was used in the description.

Use the SKU value to identify the dimensions for this product such as width, height, depth, and weight from other online sources. If you find conflicting information, use the product description from the sources you found to select the product that is most like the description of this item. Return those values into the matching response fields.

Create a custom field named "OpenAI Dimension Explanation" and explain the source of the dimensions you returned and if you did not return any values, explain why here.

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 Sku 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

  1. Manual Sync a Product with a complete record and confirm the outbound transfer succeeds and an enrichment request is accepted by OpenAI.

  2. Confirm the enriched Description arrives on the Product after OpenAI completes, via the return leg.

  3. Remove the Id mapping, attempt a transfer, and confirm the expected error is raised before any request is sent.

  4. Set ModelInstructions to malformed JSON, attempt a transfer, and confirm the parsing error is raised.

  5. Subscribe the product/created and product/updated triggers, update a Product, and confirm an automatic transfer fires.

  6. Replace the shipped PromptText with a business-specific instruction and confirm the returned values land in the intended fields.

  7. Ask the instruction to produce a custom field that has no mapping, and confirm the value is discarded — verifying the custom-field rule above.

Validation Checklist

  • The Id mapping is present and sourced from a value that uniquely identifies the Product.

  • 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.

  • The OpenAI webhook has been created in the OpenAI console and points at this subscription.

  • The Message and Product TO collections are enabled.

  • The overwrite decisions on the return leg have been recorded.

Additional Notes

  • Enrichment consumes OpenAI usage per record. Consider adding a mapping filter to restrict which Products are submitted before enabling automatic transfers on a large catalogue.

  • Bulk initialization is not supported. To enrich an existing catalogue, use bulk sync using Postman.

  • Polling is not supported; transfers occur by outbound trigger or Manual Sync.

Related Documents

Did this answer your question?