Summary
Locations can be created and updated in Shopify from iPaaS.com Location data. This collection supports the Add/Update sync type: on Add it creates a new location in Shopify and links it by saving the Shopify location id; on Update it edits the existing linked location's name and address. If a matching Shopify location is found, the integration reactivates it when it is deactivated and updates it instead of creating a new one. (See Collision Handling for a known edge case where a same-named location that is already deactivated in Shopify can still produce a duplicate.)
ID Format
Manual Sync ID.
On the iPaaS.com Manual Sync page, enter the iPaaS.com Location Id (for example, 25461) to send that location to Shopify.
External ID.
After a successful sync, the Shopify location id is saved as the external id on the iPaaS.com Location. Subsequent updates use that link to edit the same Shopify location rather than creating a new one.
Deleted Record Support
Deletion and deactivation are not performed by this collection. Removing or deactivating a location in Shopify is a manual action carried out in the Shopify admin under a supervised process. Delete mappings are not included in the default template, and deletions in iPaaS.com do not propagate to Shopify.
Custom Field Support
Custom fields mapped to Shopify through this collection are written to the Shopify location as metafields, on both Add and Update. The default template does not include a custom field mapping; add one when your store records extra information against a location. For a one-to-one mapping, set the mapping Type to Field, choose Custom Field as the iPaaS.com source, and pick the corresponding field. This is separate from the address mappings in the Mappings table below, which read values out of iPaaS.com Location custom fields into standard Shopify address fields.
Naming the custom field.
Name the destination custom field for the metafield you are targeting, in the form namespace.key:
Namespace. A name beginning with global. writes to the global namespace. Every other name writes to the custom namespace — including a name carrying some other prefix, so myapp.store_region still writes to the custom namespace rather than a myapp one.
Key. The portion after the first period becomes the metafield key, and spaces are replaced with hyphens. custom.store_region writes to the store_region key, and Store Region (no period) writes to the Store-Region key.
Defining the metafield in Shopify.
Whether you need to define the metafield in Shopify first depends on what it must hold:
A location metafield definition already exists in Shopify with a matching key: the value is written using that definition's namespace and content type. This is also the only way a value reaches a namespace other than custom or global. Define the metafield in Shopify before mapping it when it must hold anything other than plain text.
No matching definition exists: the metafield is created on the location as a single line text field.
Custom fields with an empty name or an empty value are skipped and are not sent to Shopify.
MetaObject Support
Beyond writing custom fields as simple metafields (see Custom Field Support above), this collection can build a Shopify metaobject from iPaaS.com Location custom fields and link it to the location. A metaobject lets a location carry a richer, structured record — many typed fields — rather than a single value. Metaobject mappings use a special custom-field naming pattern and require one-time setup in Shopify.
Setup required in Shopify.
Before mapping any metaobject fields, two things must already exist in your Shopify store. The integration reads and writes them but does not create them for you, so you must add them first:
A metaobject definition. The metaobject's own schema — its fields and the data type each field holds. Create it in Shopify's Custom data settings and define every field you intend to map. This is your data model; you choose the fields and their types.
A Location metaobject reference metafield. A metafield definition on the Location type whose content type is a reference to the metaobject definition above. It is created once and applies to every location in the store — it is not created per location. This is where the integration stores each location's link to its metaobject.
If the Location metaobject reference metafield definition is missing, metaobject fields are skipped silently — no metaobject is written and no error is raised. If the store has no Location metafield definitions at all, a metaobject transfer fails with a clear error. Add both definitions before mapping.
Naming the metaobject custom fields.
Metaobject mappings use destination custom fields whose names end with _MetaObject. There are two kinds:
Root field. Its name is the metaobject definition's display name followed by _MetaObject (for example, Example Existing Metaobject_MetaObject). Its value is the key or name of the Location metaobject reference metafield you created in setup (for example, example_location_metafield). This value names where the link is stored; it is not metaobject data. Enter the metafield's bare key or name — do not add a namespace prefix such as custom. or global..
Field entries. One per metaobject field you want to populate. Each name is the metaobject field's key, then the definition's display name, then _MetaObject (for example, single_line_text_Example Existing Metaobject_MetaObject populates the field keyed single_line_text). Its value is the data for that field, and the field key must exactly match a field on the metaobject definition.
A complete example, for a metaobject definition named Example Existing Metaobject whose reference metafield is keyed example_location_metafield:
Example Existing Metaobject_MetaObject → example_location_metafield
single_line_text_Example Existing Metaobject_MetaObject → Hello
integer_Example Existing Metaobject_MetaObject → 42
The metaobject definition name used in these custom-field names must match the definition's display name exactly (case does not matter) and must not contain an underscore.
Field value formats.
Each field entry's value is sent to Shopify as text and validated against that field's type. Simple types accept the plain value; structured, reference, and list types need a specific format, and an incorrectly formatted value fails the transfer. The table gives an example value for each type:
Metaobject field type | Example value to enter |
Single-line text | Hello world |
Multi-line text | text with line breaks (line breaks are preserved) |
Integer | 42 |
Decimal | 10.5 |
True/false | true |
Date | 2026-01-15 |
Date and time | 2026-01-15T10:30:00Z |
URL | |
Color | #1A2B3C |
Language | en (a two-letter language code) |
JSON | {"note":"any valid JSON"} |
ID | any text id — for example EXT-123 |
Money | {"amount":"10.50","currency_code":"USD"} |
Rating | {"value":"4","scale_min":"1","scale_max":"5"} |
Measurement (weight, volume, dimension) | {"value":2.5,"unit":"MILLILITERS"} — unit is Shopify's code for that measurement |
Link | {"text":"Example","url":"https://example.com"} — both text and url are required |
Reference (product, file, page, metaobject, and so on) | the referenced item's Shopify id — for example gid://shopify/Product/1234567890 |
A list of any of the above | a JSON array of the single value — for example ["a","b","c"], [1,2,3], or (for references) ["gid://shopify/Product/1234567890","gid://shopify/Product/9876543210"] |
A few types enforce extra rules: a choice field accepts only its configured choices; an email (or other pattern) field must match its pattern; a list field with a size limit must hold at least the minimum and at most the maximum number of items. A value that breaks any of these fails the transfer.
Referencing another metaobject (a subcollection).
A metaobject field can reference another metaobject — often used to model a "subcollection." Its value is the referenced metaobject's Shopify id (not a name, and — for a single reference — not JSON). The integration references an existing metaobject; it does not create one, so create the target in Shopify first and copy its id. For a field keyed metaobject_field on the Example Existing Metaobject definition:
In Shopify, open the metaobject you want to reference and copy its id (it looks like gid://shopify/Metaobject/1234567890).
Add a field entry custom field metaobject_field_Example Existing Metaobject_MetaObject with that id as the value.
If the field holds a list of metaobject references, use a JSON array of ids instead: ["gid://shopify/Metaobject/1234567890","gid://shopify/Metaobject/9876543210"].
Current limitations.
At the time this documentation was written:
Nested metaobjects are not created for you. A reference field can point at a metaobject or other record that already exists (by its Shopify id), but this collection does not create nested or subcollection metaobjects. Create them in Shopify first and reference them by id.
Field keys must exist on the definition. Every field entry's field key must be defined on the metaobject definition. An unrecognized field key fails the whole transfer with a clear error.
Definition-name restrictions. The metaobject definition's display name — used in the custom-field names — must not contain an underscore and must match the definition exactly.
Empty values are skipped. A field entry left empty is not sent, so it cannot be used to clear a metaobject field.
Mapping Collection Status
Status: Enabled
Trigger Events: the Location Create (
location/created) and Location Update (location/updated) outbound triggers (enabled per Setup Requirements below)
Duplicate or Conflicting Mappings
Collision Handling.
This collection uses the Update and Link collision handling method. Shopify enforces unique location names. If Shopify rejects a create because a location with the same name already exists, the integration finds the existing location by its Name (including deactivated locations), links it by saving its id as the external id, and completes the transfer as an update instead of creating a duplicate. If the matched location is deactivated, it is reactivated as part of that recovery.
Known Limitation — Deactivated Same-Name Location.
Collision recovery fires only when Shopify rejects the create because the name is already taken by an active location. If a location with the same name exists but has been deactivated in Shopify, the create can succeed and produce a duplicate (new, active) location instead of reactivating the deactivated one. This is uncommon — deactivating a location is a deliberate, business-driven manual action — but if it occurs, reactivate the intended location in Shopify (or remove the duplicate) and keep location names unique.
Exact-Name Requirement.
Collision recovery requires the Name to match exactly. If no exact name match is found despite the conflict, the transfer fails with a clear error. Recovery runs only while the collision handling method on this collection is set to Update and Link; with any other method the conflict surfaces as a normal transfer failure and no link is created.
Conflicting Collection — Inbound Overwrite Risk.
The inbound Shopify Location To iPaaS collection transfers Shopify locations back into iPaaS.com and maps only the Name field. Because the iPaaS.com API replaces the entire record on update, an inbound transfer through that collection overwrites every unmapped iPaaS.com Location field — so a location created or edited through this FROM-iPaaS collection can lose values when Shopify's change is echoed back inbound.
Warning — Unmapped Field Overwrite Risk: The iPaaS.com API uses a full record replace when updating Location records. The fields Parent, Type, and Description are not mapped in the default Shopify Location To iPaaS template, so any existing values in them are overwritten with empty/null each time an inbound transfer runs. To preserve a value, add a Dynamic Formula mapping on the Shopify Location To iPaaS collection that sources it from the existing record — for example, map DestinationValue.Description to the iPaaS.com Description field. Apply the same approach to any other Location field that must survive inbound updates.
Supported Child Collections
None. This is a standalone collection with no dependent child collections.
System Caveats
Shopify Caveats.
Name is required and must be unique within the Shopify store. Shopify rejects a create or rename that duplicates an existing location's name (including deactivated locations). Duplicate-name creates are recovered by collision handling; a duplicate name on an update surfaces as a transfer failure.
Country is required. Shopify will not accept a location without a valid country.
Activation, not deactivation. The integration can reactivate a location it finds deactivated before updating it, but it never deactivates a location.
iPaaS.com Caveats.
Country must be resolvable. The country on the iPaaS.com address must translate to a country Shopify recognizes; an unmapped or invalid country fails the transfer.
Name is the match key before linking. When no external id is saved yet, matching and collision recovery rely entirely on the location Name. Renaming a location in iPaaS.com before it has been linked can cause a new Shopify location to be created instead of updating the intended one. Sync the location once to establish the external-id link before renaming.
Setup Requirements
iPaaS.com Configuration.
Automatic transfers are enabled in the subscription configuration's Outbound Data Flows section. Subscribe to the Location Create (location/created) and Location Update (location/updated) outbound triggers that should dispatch this collection to Shopify. No automatic transfers occur until those outbound subscriptions are enabled. Whether a transfer creates a new Shopify location or edits an existing one is decided by whether it is already linked by external id (or matched by name), not by which trigger fired. Locations can also be sent on demand from the Manual Sync page using the iPaaS.com Location Id — Manual Sync does not require the outbound triggers.
Shopify Configuration.
The Shopify connection must be authorized with permission to read and write locations. No additional per-location configuration is required in Shopify.
Integration Flow
Resolve the Shopify location for the record from the saved external-id link.
If no external id is saved, search Shopify for an existing location by Name (including deactivated locations). An exact name match is linked instead of created.
If the matched or linked location is deactivated, reactivate it before continuing.
On Add: create a new location in Shopify with the mapped Name and address, and save its id as the external-id link.
On Update: edit the linked location with the mapped Name and address values.
Mappings
Add/Update Shopify Location FROM iPaaS.com
Description: Creates or updates a Shopify location from the iPaaS.com Location and its address. Name and CountryCode are required; the remaining address fields are optional and are omitted from the request when empty.
Mapping Type | Source Field (iPaaS.com) | Destination Field (Shopify) | Description |
Field | Name | Name | Required. The location name. Mapped from the iPaaS.com Location name; also used to match an existing Shopify location and to drive collision recovery. |
Field | Location Address Country | CountryCode | Required. The location's country. Must resolve to a country Shopify recognizes or the transfer fails. |
Field | Location Address Street 1 | Address1 | Optional. Street address. Omitted when empty. |
Field | Location Address City | City | Optional. City. Omitted when empty. |
Field | Location Address Region | Province | Optional. State / province / region. Omitted when empty. |
Field | Location Address Zip Code | Zip | Optional. Postal/ZIP code. Omitted when empty. |
Static |
| Active | Static value. When true, the integration reactivates the location in Shopify if it is found deactivated during an update. It never deactivates a location and has no effect on Add (new locations are active by default). |
Testing & Validation
Test Scenarios.
Create a new Location in iPaaS.com with a Name and a valid country, sync it, and verify a new Shopify location is created and the Shopify location id is saved as the external id.
Update the address or Name on a linked Location and verify the change propagates to the same Shopify location (no duplicate created).
Attempt to sync a Location with no country and confirm the transfer fails with a clear error.
Sync a Location whose Name matches an existing Shopify location (including a deactivated one) and confirm it is linked and updated rather than duplicated, and that a deactivated match is reactivated.
Manually sync using the iPaaS.com Location Id and confirm the location is created or updated as expected.
Validation Checklist.
New locations appear in Shopify with the correct Name and address.
The Shopify location id is saved as the external id after the first successful sync.
Updates edit the linked location and do not create duplicates.
Duplicate-name conflicts are recovered by linking to the existing location.
Missing or unresolvable country produces a clear transfer failure.
Additional Notes
Deactivating a Shopify location is intentionally out of scope for this collection and is handled manually in the Shopify admin. The integration only reactivates a deactivated location when it needs to update one that already exists.
Related Documents
Related Mapping Documentation