Connection and Authorization

Akeneo API Calls

Product Transfers

Product Variant Transfers

Prerequisite Transfers

Bundle (Kit) Transfers

All Transfers

Webhook Subscriptions

Description: The integration exchanged your Akeneo credentials for an access token and Akeneo did not return one. This happens when the connection's ClientId, ClientSecret, UserName, or Password values no longer match a valid Akeneo API connection, or when the Akeneo connection has been revoked or regenerated on the Akeneo side.

Resolution: In Akeneo, confirm the API connection used by iPaaS.com still exists and is enabled, then re-copy its client ID, secret, username, and password into your iPaaS.com subscription settings — Akeneo issues a new secret whenever a connection is recreated, so a rebuilt connection always needs its credentials re-entered in iPaaS.com. Save the settings and re-run the transfer. If the credentials are confirmed current and the exchange still fails, ask your MiSP to verify the API Url subscription setting points at the same Akeneo environment the connection was created in.

Description: The integration called the Akeneo API and the call did not succeed. The message repeats whatever detail was available — most often an Akeneo error code and message, sometimes the raw response body — together with the HTTP status code and the action that failed. This one code covers every failed Akeneo call, including the case where Akeneo was never reached at all, because the meaningful detail is the response quoted inside the message rather than the call site. Check the (Http Code: ...) value at the end of the message first — it tells you which kind of failure this is.

Resolution: Read the (Http Code: ...) value at the end of the message and the quoted detail first; together they identify the actual problem. That value is the status name — NotFound, Unauthorized, Forbidden — not the number; the numeric code, when Akeneo supplies one, appears separately inside the quoted detail as Code:404. Three cases are common enough to name:

(Http Code: NotFound): The record the integration asked Akeneo for does not exist, or the connection's user cannot read it. The quoted detail names it — for example Message:Product "{sku}" does not exist or you do not have permission to access it or Message:Category "{code}" does not exist. Confirm the product SKU or category code shown in the message exists in Akeneo and that the connection's user has read permission for it. A missing category is usually a stale or mistyped category code in your mapping configuration — ask your MiSP to check it. A missing product is usually a bad reference from a bundle item or a related product; if the reference is wrong, remove the product from the bundle's items or from the related-product association. For a bundle item, the Create Missing Bundle Items subscription setting lets the integration create the missing item in iPaaS.com provided it resolves in Akeneo; this does not apply to related products, which must exist in Akeneo or be removed from the association. See Akeneo Connections and Settings for how the two settings differ.

(Http Code: Unauthorized) or (Http Code: Forbidden): The connection's credentials or permissions changed in Akeneo. Follow the resolution for AKEN-AUTH-1001.

(Http Code: 0): Akeneo was never reached — there is no response because the connection attempt itself failed. The quoted detail is the underlying network error (a DNS failure, a TLS handshake failure, a timeout, or a refused connection). Confirm the Akeneo instance is reachable and running and that the API Url subscription setting is correct and complete for that instance. Transient network failures clear on their own — re-run the transfer. If the failure repeats with the same message, ask your MiSP to confirm the Akeneo host is reachable from iPaaS.com and that any IP allowlist on the Akeneo side still includes iPaaS.com.

Description: Akeneo returned a success status (HTTP 200 or 201), but the integration still recorded an error while handling the response — for example the response was cut short or could not be read to completion. The message names the Akeneo call that was attempted, followed by the underlying error. This is rare; a failure to reach Akeneo at all reports as AKEN-EXTN-1001 with (Http Code: 0), not as this code.

Resolution: Re-run the transfer — an interrupted response usually succeeds on a second attempt. If the same call fails repeatedly with this code, note the action named in the message and the record being transferred, and give both to your MiSP: a response that consistently cannot be read points at the specific Akeneo record or endpoint rather than at your configuration.

Description: The integration tried to match an incoming product to the existing iPaaS.com record by SKU so it could update that record instead of creating a new one, and no reliable match could be made. The transfer is stopped rather than allowed to create a duplicate.

Resolution: Confirm the product's SKU in Akeneo matches the SKU stored on the corresponding iPaaS.com product. Correct the mismatch in Akeneo and re-run the transfer. If the product genuinely does not exist in iPaaS.com yet, transfer it once so the link is established. If the SKUs match and the error persists, ask your MiSP to confirm the product's external id link in iPaaS.com was not broken by an earlier partial transfer.

Description: The same duplicate-prevention safeguard as AKEN-BIZL-1001, raised when your subscription identifies Akeneo products by Identifier rather than by UUID. The incoming product's identifier could not be matched to an existing iPaaS.com record.

Resolution: Confirm the Akeneo Product ID Format subscription setting matches how your Akeneo instance identifies products, since that setting decides whether the integration matches on UUID or on Identifier. Then confirm the identifier in Akeneo matches the value stored in iPaaS.com, correct any mismatch in Akeneo, and re-run the transfer.

Description: The integration tried to match an incoming product variant to an existing iPaaS.com variant by SKU and could not, so the transfer is stopped to avoid creating a duplicate variant.

Resolution: Confirm the variant's SKU in Akeneo matches the SKU on the corresponding iPaaS.com variant, and that the variant's parent product has already transferred successfully — variants transfer only as children of an existing base product. Correct any SKU mismatch in Akeneo and re-run the transfer.

Description: A variant was being transferred, but its parent product did not yet exist in iPaaS.com and the integration's attempt to create it first failed. Because variants transfer only as children of their base product, the variant transfer is stopped.

Resolution: Find the parent product's own transfer in the error logs and resolve the error reported there — that is the real failure. Once the parent product transfers successfully, re-run the variant transfer.

Description: Before transferring the current record, the integration tried to create or transfer a product it depends on, and that prerequisite transfer failed. The current transfer cannot proceed without it.

Resolution: Look up the prerequisite product by the ExternalId shown in the message and find its own failed transfer in the error logs; resolve that error first — a missing required field on the prerequisite product is the most common cause. Then re-run the original transfer. If the dependency is a related product you do not need enforced, the Skip Related Product Pre-requisite subscription setting controls whether related-product prerequisites are required.

Description: The same prerequisite failure as AKEN-BIZL-1004, raised on a path where the prerequisite product is identified by its SKU rather than its ExternalId.

Resolution: Look up the product with the SKU shown in the message, resolve the error reported against its own transfer in the error logs, and re-run the original transfer.

Description: While transferring a bundle (kit), the integration tried to create a component product the bundle depends on and could not, so the bundle transfer is stopped.

Resolution: Confirm the component product with the SKU shown in the message exists in Akeneo and transfers to iPaaS.com successfully on its own, then re-run the bundle transfer. The Create Missing Bundle Items subscription setting controls whether the integration attempts to create missing bundle component products at all.

Description: The bundle names a default component product, and the integration could not create it in iPaaS.com, so the bundle transfer is stopped.

Resolution: Confirm the default component product with the SKU shown in the message exists in Akeneo and can transfer on its own. Correct the bundle's default component in Akeneo if it points at a product that no longer exists, then re-run the bundle transfer.

Description: The integration was given an identifier it cannot use for that record type, and rejected it. Records identified by a number — product inventory, bundle components, product units, related products — reject any value that is not a whole number. Records identified by text — products, categories, attributes — reject an empty value. The check runs inside the integration before any call to Akeneo, so nothing was sent to Akeneo and no data changed in either system. The message names the record type and shows the exact value that was rejected.

Resolution: Note the record type and the rejected value shown in the message — together they are the whole diagnostic. The identifier is supplied by the transfer request itself rather than by a subscription setting you can edit, so there is no self-service correction for this error. Report both values, along with the time the error was recorded, to your MiSP, who owns the mapping configuration that produces record identifiers. If your MiSP confirms the mapping is correct, contact iPaaS.com Support at support@ipaas.com with the same details.

Description: The integration attempted to register or update the Akeneo webhook subscription that delivers change notifications, but no active Akeneo connection was available at that moment.

Resolution: Confirm the Akeneo connection is configured and validating — resolve AKEN-AUTH-1001 first if the connection is failing — then re-save the subscription so the webhook registration is retried. If the connection is healthy and the error repeats, contact iPaaS.com Support at support@ipaas.com with the subscription id and the time the error was recorded.

Akeneo Installation Instructions

Akeneo Connections and Settings

Akeneo API Endpoints

Akeneo Integration Known Limitations

Akeneo Mapping Collections