Resources: Integration Guide

using the paccurate resource enabled endpoint this document outlines the design specifications for passing slugs to the custom resource wrapper endpoint this integration allows users to access their resources efficiently and simplifies the process of composing sophisticated packing requests paccurate’s public resource enabled endpoint is https //resources api paccurate io https //www notion so/resources integration guide 717d3a1d24db4f36b7a7b4103374bace?pvs=21 background the paccurate rest api can be integrated with any erp, wms, or tms that can make rest calls however, these systems are not always able to save paccurate specific configuration items such as packing rules, settings, dynamic box types, etc paccurate’s solution to this is resources the ability to save various components of an api request that cannot be saved or easily manipulated within a user’s system of record resources can be created, tagged, updated, and deleted using type specific uis and then consumed by paccurate applications in their optimal format users are then able to access their resources with a url endpoint that is associated with their api keys this endpoint will fetch resources on the fly and store them for subsequent requests 🗄️ working with resources docid\ vre0rf8h2cz rdkh kjlj how it works user creates a resource in the resources ui paccurate saves the resource with a unique slug paccurate generates a unique proxy url to handle user’s resources, or uses https //resources paccurate io client makes an api request to the proxy, including resources array as part of the payload proxy makes a request to the resources endpoint (manager paccurate io) and saves the response of the resources array as a json string in memory it is then used on all subsequent calls that share the same array of resources request is made to the api with the merged payload, and the response is sent back to the client client saves values from response integration requirements user configurable fields api url the user’s resource handler url paccurate will supply this to the user (if not configured, user can use https //resources api paccurate io ) api key used to authenticate with paccurate services & api used in post’s authorization header resources a list of strings, each string being the unique slug for the pack resource order fields (from integrator system) item sets (required) the items in an order, with their dimensions, weight and quantity box types (optional) boxes (or other carton types) with their dimensions and maximum weight optional if using stored carton types as a resource rules & settings (optional) rules, settings, and other advanced paccurate configuration can be stored as a resource and managed on the paccurate side, or hard coded into each request some settings may be universal for your integration, and then can be augmented by user specific settings or rules order id (optional) it is strongly recommended to pass a unique order identifier with each request this helps associate requests to paccurate with orders within the wms or system of record users can utilize this field to find orders within paccurate example payload { "itemsets" \[ { "refid" 8988, "name" "item1", "weight" 0 25, "sequence" "", "dimensions" { "z" 11, "y" 10 25, "x" 3 }, "orderid" "4321545116a", "quantity" 13 },{ "refid" 8988, "name" "item2", "weight" 0 25, "dimensions" { "z" 4, "y" 6, "x" 5 }, "orderid" "4321545116a", "quantity" 2 } ], "orderid" "432154511a", "boxtypes" \[ { "name" "box a", "dimensions" { "z" 12, "y" 16, "x" 18 } },{ "name" "box b", "dimensions" { "z" 10, "y" 6, "x" 8 } } ], "packresources" \[ 	 "rules source file rules resource 64", 	 "ratetable create 66" ] } composing requests in order to leverage resources, you first have to create resources in https //manage paccurate io upon resource creation, each resource has a slug generated — these are values that the packing endpoint will use to merge the resources into payload for cartonization what to include in the payload should depend on your pack requirements for example, if you want to save your cartons as a resource, then it is unnecessary to send carton data as part of the payload, the resource reference would override it { "itemsets" \[ { "refid" 0, "weight" 1, "dimensions" { "x" 3, "y" 14, "z" 18 }, "quantity" 6, "name" "shirt" } ], "orderid" "321654", "boxtypedefaults" { 	 "weightmax" 50 	 }, "packresources" \["custom cartons 167"] } a more complex example if a user wants to use a multi zone rate card, and the wms knows the zone and service to send, the payload should include a reference to the saved rate card as part of the resources array, while the wms would include the carrier and zone as part of the box type defaults elsewhere in the request { "itemsets" \[ { "refid" 0, "weight" 1, "dimensions" { "x" 3, "y" 14, "z" 18 }, "quantity" 6, "name" "admin" } ], "orderid" "321654", "boxtypedefaults" { 	 "ratetable" { 	 "service" "smartpost", // user defined service 	 "zone" "2" // zone 	 } 	 }, "packresources" \["my smartpost rates 177", "custom cartons 167"] } more information about building rules and settings can be found on the docid\ vre0rf8h2cz rdkh kjlj page