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

The integration does not support a bulk initial import of existing Podium records. Records are transferred through automatic events or on demand through Manual Sync.

What this means for you: to load a large set of existing records, use the bulk sync using Postman workflow rather than expecting a one-time full import.

Podium stores one Name value per contact rather than separate first and last names. When transferring a contact into iPaaS.com, the integration uses the first word of the name as the first name and the remaining words as the last name.

What this means for you: review this split if your contacts commonly use multi-word first names, and adjust the mapping if a different split is needed.

A Podium contact can carry multiple emails and phone numbers. When transferring a contact into iPaaS.com, the integration uses the first email and the first phone number. When writing a Customer out to Podium, only the Customer's first address is sent.

What this means for you: confirm that the first email, phone, and address on each record are the ones you want synchronized.

iPaaS.com requires each Customer to have a unique email address. A Podium contact without an email address cannot be transferred into iPaaS.com.

What this means for you: ensure contacts carry an email address before enabling the contact transfer.

The integration transfers new and changed invoices and their payments. It does not remove a Transaction in iPaaS.com when an invoice is removed or voided in Podium.

What this means for you: if an invoice is voided in Podium, update or remove the corresponding Transaction in iPaaS.com through your own process. If your workflow needs voided invoices to propagate automatically, submit a feature request to your iPaaS.com partner channel describing the behavior you need; input like this informs future enhancement releases.

Contact deletion flows one way: when a contact is deleted in Podium, the matching Customer is removed in iPaaS.com. The reverse is not supported — deleting a Customer in iPaaS.com does not remove the contact in Podium.

What this means for you: manage contact deletions from the Podium side when you want them reflected in iPaaS.com.

Every Podium invoice operation is scoped to a location. Reading invoices into iPaaS.com uses the Location subscription setting, and writing invoices to Podium uses the invoice's locationUid value.

What this means for you: set the Location subscription setting to a valid Podium location, and populate the locationUid custom field on Transactions you send to Podium. A missing or unrecognized location prevents the invoice from transferring.

Podium requires the combined total of an invoice's line items to be greater than 50 cents. An invoice whose line items total 50 cents or less is rejected when writing to Podium.

What this means for you: ensure invoices sent to Podium meet this minimum. Your MiSP can adjust the check in the mapping filter if Podium's requirement changes.

When recording a payment on an invoice transferred into iPaaS.com, the payment method (the Podium card brand) must match the name of a Payment Method configured in iPaaS.com, or the payment is rejected.

What this means for you: create a Payment Method in iPaaS.com for each card brand Podium can return, or add a lookup translation that maps Podium's card brands to your configured Payment Method names.

The default template ships with example values that each subscriber must replace during implementation:

What this means for you: review these values before go-live so records are associated with your real Podium locations and capture the data you intend.

This document covers 9 known limitations. For detailed field-level behavior, see the Podium mapping documentation articles.