Connect: Site Flow Guide

This flowchart shows the steps to configure the integration: enabling the plugin, entering API credentials, mapping products, setting shipping mappings, and configuring Site Flow triggers. It visualizes the sequence from an admin perspective, ensuring nothing is missed during setup.

This diagram depicts the end-to-end order journey. Starting from a customer placing an order on the Infigo storefront, it then shows the plugin sending the order to Site Flow (with an asynchronous call), Site Flow processing the order (fetching files, printing, shipping), and finally the triggers sending status updates back to Infigo (order shipped with tracking, etc.). This helps in understanding how information moves between the systems at each stage.

1. Obtain the plugin (if not already licensed):

   • Make sure you have the Connect: Site Flow plugin as part of your Infigo package. If not, contact Infigo support or sales.
   • Once available, it must be activated on each storefront where you intend to use it.

2. Enable the plugin on your storefront:

   • Log into Infigo Admin for the specific storefront.
   • Navigate to Connect Settings (you can type “Connect Settings” in the admin search bar to find it quickly).
   • Under Enabled Connect plugins, check the box for Connect: Site Flow, then Save your changes.
     • Immediately after saving, you can search for “Connect” again to go to Connect Plugins, where Site Flow will now appear as an option.

3. Verify the plugin is visible in Connect Plugins (Optional Check):

   • Return to the admin menu, search “Connect” again, then click Connect Plugins.
   • You should see Connect: SiteFlow in the list, alongside any other available Connect modules (e.g., EasyPost).
   • If you don’t see it, ensure you saved your changes in the previous step.

4. Pitfalls & Tips:

   • Must Enable Per Storefront: In a multi-store setup, repeat these steps for every storefront that requires Site Flow integration; simply activating it on one storefront won’t propagate it to others.
   • Brand Centre Setting: If you see a “Brand Centre Routing Code” field later in the configuration but you don’t use HP’s Brand Centre, you can ignore it.
   • Why This Matters: If you skip enabling Connect: Site Flow, none of the integration features—such as shipping method mapping or product submission—will be available. You won’t even see the Configure button for the plugin in Connect Plugins.

With the plugin now enabled, you’re ready to configure your Site Flow connection (API credentials, product mappings, shipping setup) in the next steps. If you do not see Connect: SiteFlow under Connect Plugins, ensure you completed this activation step correctly and saved your changes.

1. Locate Your API Credentials in HP Site Flow

   • API Key: A token/key string you get from HP Site Flow (sometimes referred to as PrintOS).
   • API Secret Password: The secret key paired with the API Key, used to sign requests.
     • An Infigo user asked if the plugin uses SHA-256. Currently, the plugin does sign requests with HMAC SHA256, but if you are unsure, double-check with Infigo support or your Site Flow account manager.

2. Determine Your Destination Code

   • This field typically matches your Site Flow account name, shown in the Site Flow dashboard or provided by your HP Site Flow rep. In the Site Flow API JSON, it corresponds to "destination.name".
   • If you operate multiple brand environments or print sites, be sure to pick the correct code for the store you’re integrating—especially if you have multiple “Destination” entries in HP. If you do not plan to use HP’s “Brand Centre,” you can ignore any Brand Centre Routing Code fields that appear in the plugin config.

3. Check or Confirm the API URL/Endpoints

   • Base API URL: Usually defaults to https://pro-api.oneflowcloud.com. This covers general actions like checking order status or cancellation.
   • Additional Endpoint (asynchronous calls): For order submission, Infigo often defaults to https://orders.oneflow.io—meaning orders are queued asynchronously. If your HP rep or Infigo indicates a different URL (e.g., for a sandbox or region-specific server), use that instead.
   • Some older plugin versions or advanced setups might require changing the “Account/Provider” setting from “One Flow API” to “HP API” or “Partner API.” This is mostly legacy. If concerned, confirm with Infigo Support which you need.

1. Navigate to the Connect Plugins page

   • In Infigo Admin, search for “Connect plugins” or locate it under the Admin menu.
   • This lists all available Connect integrations on your platform (e.g., SiteFlow, EasyPost, etc.).

2. Open the Site Flow Plugin Configuration

   • Find Connect: SiteFlow in the list of plugins.
   • Click Configure to access the Site Flow plugin configuration page.
   • 

3. Fill in the API Configuration Section

   • API Key: Paste the HP Site Flow (PrintOS) API key you obtained.
   • API Secret Password: Paste the secret associated with that key.
     • Check for leading/trailing spaces and verify case sensitivity; these cause many login errors.
   • Destination Code: Enter the exact name or code of your HP Site Flow destination.
     • If you have multiple brand or production sites, confirm you’re using the correct code for this storefront.
     • If you do not use HP’s Brand Centre features, you can usually ignore the “Brand Centre Routing Code” field.

4. Review the Endpoint Fields

   • API URL / Endpoint: Typically defaults to https://pro-api.oneflowcloud.com for standard order actions (e.g., status checks, cancellations, etc.).
     • Legacy Settings: You may see an “Account/Provider” dropdown (e.g., “One Flow API,” “HP API,” “Partner API”). Most modern scenarios default to One Flow API or HP API. Double-check with Infigo if you’re unsure.
   • Additional New Endpoint (if shown): For asynchronous order submission, Infigo often uses https://orders.oneflow.io.
     • Setting this endpoint triggers async mode—Infigo sends orders to Site Flow, which queues them, and “no news is good news” unless Site Flow posts back an error.

5. Brand Centre Routing Code (Optional)

   • If you have a multi-site brand scenario or HP’s brand centre environment, enter your routing code here. Otherwise, leave it blank.

6. Save the Configuration

   • Click Save before leaving the page.
   • It’s easy to forget to click Save—always do that first, or your changes won’t apply.
   • 

7. Test the Connection

   • Return to the Connect Plugins list, find the Site Flow entry, and click Check Connection.
   • A green success means Infigo communicated with Site Flow successfully using the API Key, Secret, and Destination.
   • 
   • If you see errors (like “Missing Authentication Token” or “Forbidden”):
     • Confirm your Key and Secret are correct.
     • Confirm you used the right “Account/Provider” option if you changed it from the default.
     • Double-check the Destination Code exactly matches what Site Flow provided.
     • If everything looks correct yet it still fails, contact Infigo support—there may be a permission setting, encryption mismatch, or an outdated endpoint on the Site Flow side.

8. Pitfalls & Reminders

   • Wrong Destination Code: Orders may be rejected or misrouted if this doesn’t match exactly.
   • Typos in Key or Secret: Even a small error will cause the check to fail.
   • Don’t skip “Save”: Always click Save before you do “Check Connection.”
   • No asynchronous “Receive” event: Site Flow doesn’t send a “received” webhook. Infigo assumes the order is fine unless it’s told otherwise (order errored or submission error postback).

By completing these steps, you’ll have Infigo authenticated with HP Site Flow for order submission and status tracking. Next, you can proceed to configure product mappings, shipping methods, and advanced features (like attribute mappings, multi-component splits, etc.).

Having configured your Site Flow connection, the next crucial step is telling Infigo which Site Flow product codes (SKUs) correspond to each Infigo product or variant. Without this mapping, Site Flow won’t know which actual product to produce when orders come through.

1. Where to Find the Product Mapping Interface in Infigo

1. Open Product Management

   • In Infigo Admin, go to Catalogue → Products → Product Management (or search “Products” if you prefer).
   • Click Edit on the product you want to fulfill through Site Flow.

2. Access the Variant 

   • Navigate to the Product Variants tab.

3. Locate the Connect Link Configuration

   • On this screen, look for a green “Connect Link”  button.
   • Clicking it opens the external reference mapping dialog for that item.

The green Connect Link button is scattered throughout the system—for products, attributes, addresses, etc. At this stage, make sure you’re on the Product Variant tab, allowing you to define a single SKU to a complete Infigo product.

2. Map the Site Flow SKU

In the MIS Configure dialog:

1. Select the Plugin

   • From the Plugin or External System dropdown, choose Connect: SiteFlow.
   • If you don’t see “SiteFlow” here, confirm you enabled the plugin for this storefront (Step 1).

2. Enter the External SKU

   • Find a field labeled “MIS External Reference”, “External ID”, or something similar.
   • Type in the exact Site Flow SKU (the code that identifies your product in HP Site Flow).
     • Example: If your Infigo product is “Business Card – Classic,” and Site Flow references it as BC001, put “BC001” here.

3. (Optional) Load Available IDs from Site Flow

   • In some plugin versions, you may see a button like “Load Connect Products” or “Load Available IDs from Plugin”.
   • If present, clicking it attempts to fetch SKUs directly from Site Flow’s API.
   • If it works, you can select the correct SKU from a dropdown instead of typing it manually.

4. Save the Mapping

   • Click Save (often labeled “Save MIS Attributes” or “Save Connect Attributes”).
   • Remember to save before leaving the page; a common pitfall is forgetting to finalize your changes.

3. Consider Attribute Combinations

If your product is more complex—e.g., different paper types or finishing options—each combination might have a distinct SKU in Site Flow.

1. Create Attribute Combinations

   • In Infigo, go to Attributes → Attribute Combinations for that product (found as a tab in the product's Product Variant screen)
   • Generate combinations for each relevant variant (e.g., “Gloss – A3,” “Matte – A3,” etc.).

2. Map Each Combination

   • For each combination, use the same Connect Link or MIS Configure button.
   • Enter the corresponding SKU (e.g., “BC_GLOSS_A3” or “BC_MATTE_A3”).
   • Now, when a customer selects those attributes, Infigo sends the correct SKU to Site Flow automatically.

You can “import as CSV” if you have a large number of attribute combinations to streamline setup.

4. Mapping Stock Products (If Applicable)

• If you sell stock-only items (e.g., pre-printed mugs or stored inventory) that Site Flow also tracks as “stock” SKUs, you can similarly map them in the product’s Connect Link dialog.
• Important: For stock-only orders, recall that Site Flow still requires at least one PDF-based item. The “dummy print product” logic handles that behind the scenes if no print item is present in the order.
  • You still map each stock item’s SKU the same way, but Site Flow needs the dummy SKU (set in plugin settings) to accept the order.
  • Input the SKU for the dummy product into the "PrintOS SKU for picking list product:" field.

5. Verification & Common Pitfalls

1. Case-Sensitivity & Typographical Errors

   • The plugin is strict: “SKU123” is not the same as “sku123.” Double-check the code matches exactly what’s in Site Flow.

2. At Least One Test Order

   • After mapping, place a test order in your Infigo storefront.
   • Confirm it successfully appears in Site Flow. If not, look for an “Unknown SKU” or “Number of components is wrong” error in the logs.

3. Remember to Map All Relevant Items

   • Any Infigo product not mapped to a Site Flow SKU will fail at submission.

4. Attribute Mappings vs. SKUs

   • If you prefer fewer SKUs in Site Flow and rely on attributes (e.g., “paper type,” “binding”), you can set “IncludeAttributes = 1 (or 2)” and map attributes individually rather than making multiple SKUs.
     • This is covered in Step 5.
   • Alternatively, if you do have multiple distinct SKUs in Site Flow for each attribute combination, you must set those combos in Infigo.

5. Dummy Print Product for Stock-Only Items

   • If you see an error referencing “PDF required” for a stock item, confirm you have the dummy print SKU set in plugin config and that your actual stock item is mapped to its real Site Flow SKU. The plugin merges them behind the scenes.

Conclusion

Mapping Infigo products to Site Flow SKUs is essential for orders to flow seamlessly. Each product, variant, or attribute combo must have the correct External ID for Site Flow to recognize what to produce. With these mappings in place, you’re ready to test and move on to advanced features like multi-component products, shipping method mappings, and more.

Depending on how your HP Site Flow setup handles different product specifications (e.g., paper type, finish, color), you may need to pass attributes from Infigo to Site Flow. In some cases, each attribute combination maps to a unique Site Flow SKU (as seen in step 4); in others, Site Flow expects an attribute object (like “Finish”: “Gloss”) rather than a separate SKU.

1. Determine If You Need Attribute Mapping

1. Unique SKU Per Combination (as seen in Step 4)

   • If Site Flow has a separate SKU for each variant (e.g., “Product A – Gloss” vs. “Product A – Matte”), use Product Combinations in Infigo. Each combination has its own Connect: SiteFlow SKU entry.
   • Example: “BC-Gloss-50”, “BC-Matte-100”, etc.

2. Common SKU with Attribute Values

   • If Site Flow uses one SKU but expects an attribute field (like “Color: Red” or “Finish: Gloss”) in the JSON, you need to pass that via Infigo attributes.
   • You do this by mapping each relevant Infigo attribute (or specific attribute value) to the attribute name/value Site Flow expects.

3. Informational Attributes Only

   • If Site Flow doesn’t strictly require an attribute, you might omit it. However, some businesses still pass it for clarity/tracking.

Some users prefer fewer SKUs in Site Flow but rely on dynamic attributes; others define unique SKUs in Site Flow for each variant. Decide which approach suits your workflow.

2. Configuring Attribute Pass-Through in the Plugin

Open the Site Flow plugin configuration in Infigo (Step 2 or 3 from earlier) and locate:

1. Include Product Attributes

   • 0: Do not pass attributes at all.
   • 1: Pass only mapped attributes (the recommended approach if you have a lot of system/hidden attributes you do NOT want to send).
   • 2: Pass all attributes. (Be cautious—this can send Infigo's internal attributes (such as those required in a MegaEdit product) that Site Flow doesn’t need.)

2. Mapped vs. Unmapped

   • If you choose IncludeAttributes = 1, you must explicitly tell Infigo which attributes to send.
   • To do so, edit each attribute (or its values) assigned to the product you wish to link with Site Flow and click the green Connect Link button. Enter any text (e.g., “TRUE”) in the external reference field to mark it as mapped.
   • Any non-blank entry flags the attribute as “send this to Site Flow.”

3. Aligning Attribute Names/Values

   • If Site Flow expects an attribute named “Finish” with allowed values “Gloss” or “Matte,” ensure your Infigo attribute name is also “Finish” (or that you’re at least consistent in what you pass).
   • Case-Sensitivity: “MATTE” might fail if Site Flow expects “Matte.”
   • If Site Flow just needs a free-text value, be sure your Infigo attribute can accept it (text field or dropdown) and that you pass the same strings.

3. Mapping Attributes in Practice

1. Edit the Infigo Attribute

   • Go to Product Management > [Edit Product] > Product Variant [Tab] > Edit > Attributes [Tab]  in Admin.
   • Locate the attribute you want to pass (e.g., “Finishing”).

2. Click the Connect Link / MIS Configure

   • Select Connect: SiteFlow in the dropdown.
   • Enter the External ID or code that matches Site Flow’s naming (if Site Flow specifically requires a code). If there’s no special code, simply put something non-blank (like “true”) to ensure it’s marked as mapped when IncludeAttributes=1 is set.

3. For Attribute Values (if needed)

   • If each value needs its own code in Site Flow, click the green Connect Link on each value to provide a distinct external reference (e.g., “Matte=MAT,” “Gloss=GLO”).
   • Otherwise, if Site Flow just consumes the label as typed, you can skip value-level mapping.

4. Save

   • Always click Save or “Save MIS Attributes” before leaving the page.

4. Handling Advanced / Calculated Attributes

• Formula or dynamic fields: If you’re using Infigo’s advanced dynamic or formula-based attributes (e.g., the system calculates a dimension or page count), verify that the final value is something Site Flow can interpret.
• In some environments, you might need asynchronous order submission so that the final calculated attribute is ready at the time of sending. The transcript mentions we’ll discuss synchronous vs. asynchronous. Just note that if your attribute depends on the final PDF (e.g., page count), be sure it’s fully computed before sending the order.

5. When to Use Attribute Combinations vs. Single Attributes

• Attribute Combinations: If each combination is effectively a separate SKU in Site Flow (different finishing, size, etc.), it’s best to define each combination in Infigo and map it to that unique SKU.
• Single SKU + Mapped Attributes: If Site Flow expects one product code with optional fields specifying the finish, color, or other specifics, then set up the attribute as described above, ensuring you pass the correct attribute name/value.

6. Testing Your Attribute Setup

1. Test an Order

   • Add a product to cart with the mapped attribute(s).
   • Complete checkout. In the plugin logs (and in Site Flow) confirm the attribute(s) arrived as expected.

2. Check for Errors

   • A mismatch (e.g., “MATT” vs. “Matte”) may cause validation errors.
   • If you see “Unknown attribute” or “Invalid attribute value” in Site Flow logs, correct the names/values in Infigo.

3. Iterate

   • Adjust your plugin’s “IncludeAttributes” setting or your attribute mappings as needed until the data flow matches what Site Flow requires.

Conclusion

Mapping attributes in Infigo for Site Flow is flexible:

• Minimal approach: rely solely on unique SKUs for each variant.
• Intermediate approach: single SKU + carefully mapped attribute(s).
• Complex approach: multiple attribute combinations for many variants.

Whichever path you choose, verify naming consistency and carefully test an order. With attributes properly aligned, your Site Flow integration can handle a wide range of product specs—everything from finishing to size or color—seamlessly.

Site Flow needs to know which carrier/service (or alias) to use for an incoming order. In Infigo, you can pass this shipping information in one of two ways:

1. By specifying a Carrier Code + Service (e.g., "carrier": {"code": "UPS", "service": "Ground"}), or
2. By specifying a Shipping Alias (e.g., "carrier": {"alias": "UPSPremium"}).

Either approach is valid, but the values must exactly match what’s set up on your Site Flow account. If the names are off by capitalization or spelling, Site Flow will reject the order with a “Shipment Couriers Not Available” or similar error.

1. Where to Configure Shipping in Infigo

1. Open the Site Flow Plugin Configuration

   • In Infigo Admin, search “Connect Plugins” and click Configure on Connect: Site Flow.
   • Scroll to the Shipping Settings (or similarly named) section. You should see fields for:
     • Fallback shipping method service
     • Fallback shipping method code
     • Fallback shipping method alias
     • Shipping methods mapping (for the multiple-method mapping table)
     • SLA days fallback value (optional fallback for turnaround time—discussed in other steps)
     • 

2. Choose Your Fallback/Default Shipping Method

   • If your storefront only uses one shipping option—e.g., a single local pickup or a single standard ground—simply hard-code the defaults in the plugin.
   • For example, set:
     • Fallback shipping method code = customer
     • Fallback shipping method service = pickup
       or
     • Fallback shipping method code = UPS
     • Fallback shipping method service = Ground
   • Any order that doesn’t match a mapping below will use these defaults.
   • Alternatively, you can hard code the alias (Fallback shipping method alias) instead of the code and service.

2. Mapping Multiple Delivery Methods

If you offer multiple shipping methods (e.g., “Standard,” “Express,” “Overnight”) in Infigo, you can map each method name to a unique Site Flow carrier/service or alias:

1. Gather the Infigo Method System Names

   • In Infigo Admin, go to Shipping (or Delivery Methods) or the individual shipping plugins (such as FedEx)
     • For Infigo created methods to to Admin > Delivery Methods (or Shipping Methods)
     • 
     • For methods populated from plugins (such as FedEx) go to Admin > Delivery Computation (or Shipping Computation) > Configure [Chosen Plugin] > Get Shipping Options
     • 
   • Look for each method’s System Name (e.g., FedExStandard, Express1, etc.). This is often visible under “Get Shipping Options” or in the method’s configuration page.

2. Fill in the Mapping Table

   • In the Site Flow plugin configuration, find Shipping methods mapping.
   • Typically, you enter one row per shipping method in the format:
      

     [InfigoMethodSystemName];[SiteFlowService];[SiteFlowCode];[SiteFlowAlias]
     or whichever order the plugin UI specifies.
   • Examples:
      

     Standard;Ground;UPS;

     Premium;;;UPSPremium
     • Here, if Infigo sees “Standard,” it will send code = "UPS" and service = "Ground".
     • If Infigo sees “Premium,” it will use alias = "UPSPremium" (and no code/service).

3. Save and verify that each line is correct—particularly the case/spelling matches exactly what Site Flow expects. If anything is off, orders will fail on submission.

3. Using EasyPost or Other Carriers

1. Pulling Infigo Delivery Methods from EasyPost

   • If you have the EasyPost plugin, the shipping methods you enable in EasyPost will appear in Infigo’s shipping method list with certain system names (e.g., break_bulk_economy, express_mail, etc.).
   • You must then map these system names to Site Flow.

2. Multiple or Mixed Shipping Approaches

   • Some users want a mix of “Pick-up only” and “Carrier-based” shipping.
   • So you might have a row in the mapping table for “PickUpMethod;pickup;customer;” and another row for “ExpressMail;;;"EPExpress"if your alias isEPExpress`.

3. Fallback

   • If a shipping method is used in the storefront but not found in your mapping table, the plugin uses your fallback options.
   • Avoid surprises: either map all methods or confirm your fallback is correct.

4. Double-Check Site Flow Setup

• Confirm that the carrier/service or alias values you enter in Infigo are configured in Site Flow.
• Case-sensitivity is often enforced (e.g., UPS vs. ups).
• If you’re unsure which codes or aliases Site Flow accepts, log in to your Site Flow account or consult your HP rep.

Example JSON in Site Flow

When an order is submitted, the shipping portion might look like:

Site Flow uses this info to route the order correctly and generate the right shipping label or action.

5. Common Pitfalls

• Typos in the mapping table (missing semicolons or incorrect method names).
• Case mismatch (Site Flow says “UPS” but Infigo is sending “ups”).
• Forgetting to press “Save” on the plugin after editing.
• Not covering all shipping methods you offer—leading to unexpected fallback usage.

Summary

1. If you have one shipping method, just set the default code/service or alias.
2. If you have multiple methods, define a mapping table row for each Infigo system name → Site Flow code/service/alias.
3. Ensure those codes/services/aliases exist in Site Flow.
4. Use the fallback fields so that unmapped shipping methods won’t break your order submission.

Following these steps ensures that the shipping choice the customer selects in Infigo translates seamlessly into Site Flow, preventing shipment errors and maintaining an efficient workflow.

In some scenarios, the customer may not supply a shipping address (e.g., they chose an in-store pickup, or the storefront didn’t request it). To ensure Site Flow can still process the order (it requires a valid shipping address even if it won’t actually ship), you can configure fallback behaviors in the Site Flow plugin.

1. Fallback Shipping Address Settings

In the plugin configuration (under Connect: SiteFlow Configure), you will see a section that lets you specify how Infigo handles orders where no shipping address is set:

1. Shipping Address Fallback to Billing Address

   • If enabled, any order lacking a dedicated shipping address will use the billing address data.
   • Typical fields used: Full Name, Company, Address1/2/3, Town, Zip/PostCode, State, IsoCountry, Phone.
   • This is helpful if you often only collect a “billing” address from the customer but still need an address to pass to Site Flow’s shipments.
   • 

2. Fallback to Configured Shipping Address

   • If you prefer not to use the billing address, you can leave the above option disabled.
   • Then, the plugin will use the “dummy” or fallback address you explicitly configure (often a default warehouse or vendor location) whenever the order has no shipping address.
   • You can set these details in the plugin fields, for example:
     less

      
   • Site Flow sees this address as the “shipTo” data if no other shipping address is available.

When is it applied?

• Whenever Infigo tries to send an order to Site Flow and the standard shipping address is blank or missing.
• If “Shipping address fallback to Billing Address” is on, it tries that first. If it’s off (or if billing is also missing), it uses the explicitly configured fallback address.

2. Vendor Address Settings

You may see an option in the plugin labeled “Include vendor address”. This allows you to attach a “vendor” or “origin” address to the order—useful if:

• You want Site Flow to see the production facility or vendor’s location as part of the order data.
• You need a return address in the event of failed delivery or returns.

Once you have orders flowing from Infigo to Site Flow, you’ll likely want status updates or error notifications pushed back into Infigo—so that if an order fails or ships, Infigo can reflect the correct status. Site Flow accomplishes this via Triggers, which are essentially webhooks that call Infigo’s endpoints.

1. What Events Are Posted Back to Infigo?

Site Flow commonly sends:

• Order Submission Error: If Site Flow tries to process a newly submitted order but runs into an error (e.g. missing files, invalid SKU), a postback can notify Infigo. In the plugin, you’ll see it referred to as ordersubmissionerror.
• Order Cancelled: If someone cancels an order in Site Flow (e.g., production staff or an automatic process), a postback can inform Infigo so that the order is also cancelled in Infigo.
• Order Shipped: When an order is dispatched (shipped) in Site Flow, it can push back the tracking number (if available) and final shipping status to Infigo.

Note on “Order Received”
The transcript highlights that Site Flow doesn’t send a “received” postback by default: “No news is good news” – if there’s no “Order Submission Error,” Infigo assumes the order was successfully received. You won’t see a dedicated “received” event triggered from Site Flow.

2. Finding the Webhook URLs in Infigo

1. Open the Site Flow Plugin Configuration in Infigo

   • Typically, near the bottom of the plugin page or in the online help, you’ll see distinct endpoints for status updates.
   • Each storefront/installation has unique URLs (the <id> is specific to your store). Copy them carefully.
   • 

2. Which Endpoint for Which Event?

   • The statusupdate endpoint is for “canceled” or “shipped” events (and sometimes other general status changes).
   • The ordersubmissionerror endpoint is specifically for order submission errors.

Pitfall: Using the wrong endpoint for the wrong event will break the integration. Double-check the plugin docs for which events go to which endpoint.

3. Creating Triggers in Site Flow

Please refer to HP's Site Flow documentation for the creation of triggers within their software.

Below are some sample triggers, however it's possible the location or structure of these may change with updates to Site Flow.

You’ll create separate triggers (webhooks) for each event type:

1. Order Submission Error Trigger

   • Event: “Order Submission Error” (fires if Site Flow fails to process a new order).
   • Type: HTTP POST.
   • Template: Copy/paste the JSON recommended by Infigo. A typical template might look like:
      

     { "TimeStamp": "{{timestamp}}", "OrderId": "{{data.body}}", "status": "Order submission error", "errorsClean": [ {{#each data.errorList}} "{{#if name}}{{name}}: {{/if}}{{#if message}}{{message}}{{else}}Unknown error{{/if}}{{#if path}} - At path {{path}}{{/if}}" {{/each}} ] }
   • Address (URL): Use the Infigo ordersubmissionerror endpoint from the plugin config.
   • Headers: Add a “Content-Type: application/json” header so Infigo parses the incoming JSON correctly.
   • Linked Account: (If Site Flow prompts you) pick the same account that matches your “Destination Code” used earlier.

   Result: If an order is invalid or fails inside Site Flow, Site Flow will POST this JSON to Infigo, letting the plugin update the order in Infigo to a “submission error” state.

2. Order Cancelled Trigger

   • Event: “Order Cancelled” (fires when manually or automatically canceled in Site Flow).
   • Type: HTTP POST.
   • Template: Typically something like:
      

     { "TimeStamp": "{{timestamp}}", "SourceOrderId": "{{data.sourceOrderId}}", "Status": "cancelled" }
   • Address: The statusupdate URL from Infigo (not the error one).
   • Headers: Same as above (“Content-Type: application/json”).
   • Linked Account: If relevant, select your main Site Flow account.
   •  

   Result: When Site Flow sees an order canceled, it notifies Infigo so that Infigo marks that order as canceled as well. The transcript calls out that you won’t want a mismatch where the order is canceled in production but still open in Infigo.

3. Order Shipped Trigger

   • Event: “Order Shipped” or “Shipment Dispatched” (whichever name your Site Flow environment uses).
   • Type: HTTP POST.
   • Template: The key difference here is you typically include a “TrackingNumber” if available:
      

     { "TimeStamp": "{{timestamp}}", "SourceOrderId": "{{data.sourceOrderId}}", "TrackingNumber": "{{data.trackingNumber}}", "Status": "shipmentdispatched" }
   • Address: The same Infigo statusupdate URL as cancellations.
   • Headers: “Content-Type: application/json”.
   • Linked Account: Select your correct account.
   •  

   Result: Once production dispatches (ships) the order in Site Flow, Infigo is updated to “Shipped,” and it can store the tracking number. Customers can see their order status and tracking details in Infigo.

4. “No News Is Good News” for Successful Orders

Infigo doesn't support an "order received" postback. We send it and assume it’s being received. Then we’ve got order errored and order submission error. If we don’t get either of those back, no news is good news.

This means Infigo expects that if Site Flow doesn’t call back with an error, the order was received successfully. So, you won’t see a “received” or “print ready” postback. Instead:

• Submission error postback → means the order is not valid in Site Flow.
• No error → means it’s good to proceed.

5. Confirming Everything Works

1. Save your triggers in Site Flow with the correct JSON templates and URLs.
2. Test by placing an order from Infigo:
   • Force an error scenario (e.g., intentionally invalid SKU) to see if the “Order Submission Error” trigger fires.
   • Cancel or mark an order shipped in Site Flow’s UI to see if Infigo updates accordingly.
3. Check Infigo:
   • The order should show “Submission Error” or “Cancelled” or “Shipped” with a tracking number if all is configured properly.
4. If you see no updates or an error in the logs, re-check the URLs and Content-Type header in Site Flow triggers.

Pitfall: Any small mismatch (URL path, missing “application/json” header) can break the postback chain. Also, if you have multiple store domains or multiple Infigo storefronts, ensure you used the correct domain and plugin endpoint for the relevant store.

6. Summary

• Copy the specialized Infigo endpoints from the plugin config: one for errors, one for general status updates.
• Create 3 triggers in Site Flow: “Order Submission Error,” “Order Cancelled,” and “Order Shipped.”
• Use the JSON templates recommended by Infigo so they parse the data consistently (especially for tracking numbers).
• Remember: “No news is good news”—Site Flow won’t confirm “received,” but it will confirm errors, cancellations, and shipments.
• Test thoroughly to ensure statuses flow back into Infigo as intended.

At this point, your two-way integration is complete:

1. Infigo → Site Flow for orders.
2. Site Flow → Infigo for statuses and errors.

Your system is now ready for a fully automated workflow, with minimal manual intervention needed.

Once you’ve completed the configuration steps—mapping products, setting shipping methods, and setting up Site Flow postbacks—it’s time to verify that everything works as expected. Consider several real-world scenarios to confirm your workflow is correct:

1. Test Order Submission

1. Place a Test Order in Infigo
   • Make sure you use a product that’s mapped to Site Flow (i.e., it has a Site Flow SKU or attribute mapping).
   • Proceed through the checkout in Infigo as a normal customer would, selecting a shipping method you’ve mapped (or your default shipping if only one).
2. Check Site Flow for the New Order
   • Log into Site Flow and head to the Orders area (or “Submission Errors” if you suspect a failure).
   • If the order appears under the “In Production” or “Pre-Production” section (depending on your Site Flow setup) with no errors, basic submission is working.
   • If the order is missing entirely, check Infigo logs for any outbound error. The transcript mentions that if something doesn’t appear, it could be:
     • Invalid SKU (Site Flow will show “Product not found” or similar).
     • Unknown shipping method (“Unknown shipping method” or similar).
     • Misconfiguration (wrong credentials, endpoint issues, or a JSON formatting error—but the transcript indicates that’s less common if you used the default plugin fields).
3. Common Mistakes Caught Here
   • Typos in the mapped SKU: The transcript repeatedly notes that Site Flow will reject orders if the SKU doesn’t exactly match.
   • Unmapped shipping method: If Infigo tries to send a shipping service or alias that isn’t recognized in Site Flow, the order fails.
   • Incorrect API credentials: If the Site Flow plugin test connection passed, this is less likely, but still possible if changes were made afterward.

Tip: If your test order fails, check the Orders page in Site Flow for “Order Submission Error” or the Infigo logs to see the exact message. Debug accordingly.

2. Test Status Updates from Site Flow

Site Flow can notify Infigo about key events like shipment or cancellation. Let’s confirm those webhooks are actually updating Infigo:

1. Mark an Order as Shipped

   • In Site Flow, find your test order (the one you just placed) and mark it as Dispatched/Shipped (often done in the order details page).
   • Site Flow should fire the Order Shipped trigger. If configured correctly, Infigo will receive a JSON with the tracking number (if provided) and update the order status to “Shipped” (or “Completed,” depending on your Infigo setup).
   • Check Infigo: The order should now show “Shipped” status, potentially with the tracking number if you added one.

2. Try Canceling an Order

   • In Site Flow, cancel another test order (or the same one if it wasn’t fully shipped). This should trigger the Order Cancelled webhook.
   • Infigo should update the order to “Canceled” (or similar) automatically.

3. Force a Submission Error (Optional)

   • If you want to test the Order Submission Error postback, you can deliberately break a product mapping (e.g., change a Site Flow SKU in Infigo to something invalid).
   • Place a new order—Site Flow will likely reject it, triggering the error callback. Infigo should record the order as errored, letting you see how it handles failures.
   • Use caution: Do this only in a test environment, not on a live storefront.

3. Troubleshooting Tips

If orders never reach Site Flow:

• Verify Infigo plugin logs (or contact Infigo Support to check for you if you do not have access)
• Confirm your API Key, Secret, and Destination Code are correct. Double-check using Check Connection in the plugin config.

If orders appear but never get updated:

• Confirm Site Flow triggers are configured and point to the correct Infigo endpoints. A single typo in the webhook URL or missing “Content-Type: application/json” header can stop everything.
• Remember “No news is good news” if you see no submission error—Site Flow doesn’t send a “received” message, so don’t expect a “success” callback. Only errors, shipped, or canceled are posted back.

If shipping methods fail:

• Shipping codes must exactly match what Site Flow expects. If you use “Fedex” in Infigo but Site Flow expects “FedEx” or an alias “Fedex_2Day,” a mismatch occurs.

If attributes or components don’t behave as intended:

• Review whether you set up attribute mapping (especially if you have multi-option products).
• For multi-component items (like books with cover + pages), ensure page split rules are correct in Infigo and the component names (cover, text, etc.) match Site Flow’s product definitions.

4. Final Checklist

1. Credentials: Infigo’s Site Flow plugin passes “Check Connection” with no errors.
2. Product Mapping: All products you want to produce via Site Flow have Site Flow SKUs or attribute combos mapped.
3. Shipping: Each shipping method in Infigo is either (a) mapped, or (b) there’s a working default if you only have one.
4. Triggers in Site Flow:
   • “Order Submission Error” → calls Infigo’s ordersubmissionerror endpoint.
   • “Order Shipped/Dispatched” → calls Infigo’s statusupdate endpoint.
   • “Order Cancelled” → also calls Infigo’s statusupdate endpoint.
5. Test Orders: Successfully submitted to Site Flow, update statuses, and handle error or shipping events properly.

Congratulations! If all tests pass, your Infigo-Site Flow integration is now operational. You’ve confirmed that orders flow into Site Flow asynchronously, and that Site Flow can push status updates or errors back into Infigo for a fully automated print workflow.