This documentation (and the My.ShipRush API generally) are Proprietary Trade Secrets of Descartes Systems Group LLC. This documentation for My.ShipRush API components build 110197 (January, 2018) and higher.
Notification API / Push API
The Notification API allows you to use My.ShipRush without polling My.ShipRush for new/changed orders. My.ShipRush "polls itself" and pushes data to your system. However, this requires that the developer using My.ShipRush implement an entry point to receive the incoming REST transactions.
By default, this functionality is turned off. To enable notifications, you can either:
Use the SDK GUI tool (shown below)
Implement the notification API calls in your application.
(It is not necessary to implement the calls described below. Many systems achieve great success by doing the initial configuration in the GUI test tool and ignoring the APIs.)
Enable it either for:
All users created by your developer key
Individually by user ID for specific users under your developer key
My.ShipRush will push the full GetShipments() payload for new and changed data, including data changed by your calls to UpdateShipment. Data is pushed frequently, typically within a few minutes of data changed date. De facto throttling may occur if the data throughput nears system capacity (however this represents an extremely high order rate which is not anticipated).
During development, it is not necessary to implement gzip. However for production use, the receiving system must accept gzip compression for XML payloads. This is indicated by the http header (present in all notifications from My.ShipRush):
Content-Type: application/xml;charset=UTF-8
Content-Encoding: gzipAuthentication: Signing the Notification Transaction
My.ShipRush signs each payload with a cryptographically strong hashing algorithm, based on a pre-shared secret. The result signature added to "X-SHIPRUSH-Signature-V1" HTTP header.
In order for the receiving system to verify that the incoming transaction is actually from My.ShipRush, this algorithm will need to be implemented and used on every incoming transaction.
X-SHIPRUSH-Signature-V1 algorithm
Get data payload as string (POST message body)
Get your developer token DeveloperToken as string (lowercase)
Calculate MD5 hash of the (data payload + developer token)
Example:
If the HTTP message body is <xml>test</xml> and DeveloperToken is 95a2054f-52d1-4892-aff6-9f8800eede30
then the signature = MD5( <xml>test</xml>95a2054f-52d1-4892-aff6-9f8800eede30 ) = 6afd666e9b7440e83fe0984f77bbf746
XML Message Encoding
The native encoding is UTF-8.
API Call and Data Flow Schematic
For Comparison: How Polling Interaction Looks
Push-Based Interaction
This document only covers the push mechanism of My.ShipRush (HTTP POST), which is an optional data delivery mechanism for order data. This document does not include the core My.ShipRush API. For other API calls, please refer to the document: "MyShipRush API for Web and Desktop Integration".
Also note that ConfigureNotification() and other notification configuration calls are not described in the chart. Often this is set up one time, even manually, and the API calls described in detail below are not implemented in your application.
Concept Mapping: Push API to Core My.ShipRush API
The core My.ShipRush API uses the UserToken as the auth and identity mechanism. The Push API uses <AccountId> as the identity element, and the signing method (above) as the authenticity mechanism.
Starting in version 2.0.0.49751 of My.ShipRush, the core My.ShipRush API returns <AccountId> in CreateUser() and GetUser() calls. Your system should persist <AccountId> along with UserToken. Depending on the call or operation, one value or the other will be needed.
Life without GetShipments()
The push mechanism described in this document is a replacement for the GetShipments() call described in the main My.ShipRush API document. The good news is that your system need not poll My.ShipRush. However, there is an implication: How does My.ShipRush know the user is still active?
Detecting Abandonment
Please review this section. If you have any questions, please consult with the My.ShipRush team.
One of the issues My.ShipRush manages is user abandonment (e.g., users who set up a Web store, but then no longer use the My.ShipRush infrastructure for shipping). Because it requires significant resources to interact with a Web store, My.ShipRush looks for signs that the user is actively using the data from My.ShipRush. If it is detected that the user has abandoned the My.ShipRush data feed, the user's Web stores are demoted to an inactive state.
You care about abandonment because a % of users will just "taste" your system/ecommerce integration. If we do not detect abandonment, this growing body of users will cause a growing amount of useless data to be pushed to your system on an ongoing basis.
By default, My.ShipRush keeps a user active for a number of hours after the last call to the API calls below. (This active window can be adjusted for your user community. Typically it is 72 hours, but this is adjusted to meet the needs of your implementation. Contact the My.ShipRush support team to discuss.)
Several interactions automatically keep a user active. For example, when your system uses GetShipments(), this keeps the user in an "active" state. Other API calls that maintain the user as active include (these calls both keep a user active, and will reactivate a user who has gone dormant):
GetShipments()
UpdateShipment()
CreateUser()
GetSessionToken()
AddTestData()
GetUser()
CreateWebstore()
DeleteWebstore()
GetWebstore()
Systems using the push mechanism should call GetUser() to signal to My.ShipRush that the user is active. For example, this can be done any time the user accesses the ecommerce functionality or screens within the consuming application (but not excessively, please!).
Abandonment is on a per-user basis, not a per-Web store basis.
Your application: What often makes sense is to have a Refresh button on your application which calls GetUser() (or another call). This allows the user to keep himself active with a simple click.
Versioning
The My.ShipRush API is a standard REST API in that it may add new XML elements within a released version. Nearly all XML parsers allow this without problems, however a few parsers are "strict" and do not allow new elements in the XML. "Strict" type parsers should not be used with payloads pushed via notifications and subscriptions from the My.ShipRush API.
HTTP Headers on the POST Operation
HTTP POST payloads include the following headers, which the endpoint can use as needed:
X-SHIPRUSH-Signature-V1 // See the section above related to authentication/signing
Content-Type: application/xml;charset=UTF-8 // clarifies the type of data
Content-Encoding: gzip // present if the payload is gzipped, see section above for discussion
Custom header: // see discussion below
Custom header2:Starting in build 58540: If your endpoint requires special headers (such as for authentication), these can be configured by the My.ShipRush admins server side. It is strongly recommended to use auth of some kind prior to the un-gzip operation. This is needed to prevent "zip bomb" attacks on your endpoint.
Getting Started
Note that it is not necessary to implement the API calls described below. Full management of subscriptions and notifications can be done via the SDK GUI tool. It is possible to set up subscriptions three ways:
Via SDK GUI Sample app (shown below)
Via email to My.ShipRush sys admins (who can set up the notification manually for your developer key, and set it to auto-subscribe your users.... and then you are done)
Via the API calls below, from your code.
Get Started with these Steps:
Create your endpoint, where notifications will be pushed to (perhaps just an endpoint that saves the post to disk for starters).
Create the notification (perhaps using the SDK GUI tool below). The notification configures the endpoint where data will be sent.
-
Have a user with a subscription (or create a new MySR user, if the "auto subscribe" option is set on the notification):
If the user was created before the notification was created, then use the SubscribeToNotification() call (or the GUI) to attach the user to the notification.
Be sure to use the tokens relevant for the user when doing this!
Optional: Add a Web store for the user (use SDK test tool below, for example).
Test out the push: Add some orders to that Web store (use SDK test tool below, for example).
Now Descartes ShipRush will push data to your endpoint!
API Calls for the Push Mechanism
(Be sure to review the note above.)
ConfigureNotification()
RemoveNotification()
GetNotificationStatus()
SubscribeToNotification()
UnsubscribeFromNotification()
GetSubscriptions()
GetSubscriptionStatistics()
Use the GUI Sample Application
The MyShipRush SDK includes a GUI sample application. This can be used to make the calls described below, in a quick, easy way.
This tool may be all you need. In many cases, you can set up your notification, configure it to "auto subscribe new users," and you are done. (You can then ignore the rest of this document, forget all the API calls discussed below and focus on your application.)
See the Push: 5-Minute Walk Through via GUI Sample App
Create a new user.
Note: If you have a user account already created, do not create a new user. Instead paste in your developer token and user token and go to the next step.
Use a post bin or Webhook test site to see the results in action. Do this only if you lack your own endpoint.
Warning: The data at these sites is PUBLIC. Allow ONLY test data into the ShipRush account, NO PII! Tip: Some of these sites do not work reliably. Before moving to the next step, TEST THE SITE using curl, fiddler, or a similar tool. If you do not see GET and POST requests logged, forget that site and use another.
In this example, we will use requestcatcher.com.
Configure a Notification for this Endpoint
Now Use the Subscribe Option to Connect the User to the Notification
The subscription is the connection from a user to the notification.
Optional: You can use GetSubscriptionStatus() at this point to see that it is wired up appropriately.
Now Go to the Shipments and Orders tab and Hit Add Pending Shipments
Wait 1-2 Minutes, and the Request Catching App Should Show the Payload
Library Support
If you use the MyShipRush provided .NET assembly, you can make all the calls below simply by using the ShipRush.SDK.dll and ShipRush.SDK.Proxies.dll assemblies.
ConfigureNotification() - Configures Notifications Entry Point
(Be sure to review the note above.)
This is how the developer configures the notification entry point and the default notification behavior. Only specified fields will be changed.
Note that for high volume consumers of My.ShipRush, My.ShipRush administrators may manually "lock" these values (with the agreement of the developer) after they have been set by the developer. This action prevents an accidental change by the developer or anyone else. Unlocking would require manual intervention by My.ShipRush administrators.
Endpoint - ConfigureNotification()
/accountservice.svc/notification/configure
Request - ConfigureNotification()
URL |
(required) Entry point for the notification payload. This is on your server. It must be SSL for production use. This is the URL of the developer system which will receive the notifications |
Notification Type |
(required) Type of Notification subscribe to |
Enabled |
Enable/Disable notifications |
AutosubscribeNewUsers |
Each new user created with your developer token will be automatically subscribed to notifications |
DataFormat |
(optional) XML only supported at the moment. Future options may include JSON/binary/etc. |
ApiVersion |
(optional) My.ShipRush schema compatibility version. If not specified the current API version is sent. (See volatility note below.) |
Transform |
(optional) Enable/Disable XSLT transformation of payload. The supported XSLT version is 1.0 . |
Template |
(optional) XSLT Template. Only used if the Transform property above is set to true. |
ErrorMessage |
(out parameter) This field shows last xslt transformation error. If an error is encountered applying the XSLT, the most recent error will be in this element. Only relevant if <Transform> is true and a <Template> is provided. |
Warning: ApiVersion is volatile, which means the payload schema and enumerations are volatile. We strongly recommend that you you send this value in your subscriptions. Only if you set an ApiVersion can you be assured of receiving a consistent payload. Please see the section in the My.ShipRush API documents titled "API Versioning in My.ShipRush X-SHIPRUSH-VERSION and more".
Sample
<?xml version="1.0" encoding="utf-8"?>
<ConfigureNotificationRequest>
<URL>https://DeveloperSystem.com/shiprush/notification</URL>
<Enabled>true</Enabled>
<NotificationType>Order</NotificationType>
<AutosubscribeNewUsers>true</AutosubscribeNewUsers>
<Transform>false</Transform>
<Template></Template>
<ErrorMessage></ErrorMessage>
</ConfigureNotificationRequest>Response - ConfigureNotification()
Returns all fields of the current subscription configuration.
<ConfigureNotificationResponse>
<URL>https://DeveloperSystem.com/shiprush/notification</URL>
<Enabled>true</Enabled>
<NotificationType>Order</NotificationType>
<AutosubscribeNewUsers>true</AutosubscribeNewUsers>
<DataFormat>XML</DataFormat>
<ApiVersion>43980</ApiVersion>
<Transform>false</Transform>
<Template></Template>
</ConfigureNotificationResponse>Notification Payload
Notification payload will have full Shipment/Order body in the POST data. MyShipRush will post up to 50 ShipTransactions in a single call.
Single notification will POST data for a single My.ShipRush account. So it is possible to have shipments that belong to different users or different Web stores in the single notification. Use Shipment.WebstoreId and Shipment.UserId to match the incoming shipment to a specific user and Web store.
This example is for the situation in which <Transform> is false. The documentation here is for the native, unmodified, order/shipment payload. If <Transform> and <Template> are in use, the schema will be according to the configured xslt.
If an XSLT is used, an easy way to test the XSLT against a sample payload is to use the tool in the SDK "ShipRush.Tests.GUI.exe" Paste the XSLT into the edit and press "Test XSLT Transformation" This performs a client side crunch of a static payload (in the "Push Notification XML" tab) against the template.
<Notification xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<NotificationType>Order</NotificationType>
<ApiVersion>43980</ApiVersion>
<ServerTime>2012-03-05T13:01:35.000Z</ServerTime>
<Data>
<ShipTransactions>
<TShipTransaction>
<Shipment>
<WebstoreName>Magento Go webstore</WebstoreName>
<WebstoreType>magento_native</WebstoreType>
<ShippingCharges>0</ShippingCharges>
<WebstoreId>9ce9a079-63a4-4487-a511-############</WebstoreId>
<AccountId>e6a11d54-34d1-472b-b9ac-############</AccountId>
<UPSServiceType>01</UPSServiceType>
<ShipmentReference1>100003076</ShipmentReference1>
<ShipDate>2012-02-28T01:09:42.000Z</ShipDate>
<ModifiedAt>2012-03-28T18:15:38.000Z</ModifiedAt>
<ShipNotificationEmail>11ka8rson@demo-email.net</ShipNotificationEmail>
<Carrier>0</Carrier>
<IsProcessed>0</IsProcessed>
<Package>
<PackageActualWeight>3.25</PackageActualWeight>
<PackageReference1>100003076</PackageReference1>
<InsuranceType>Unknown</InsuranceType>
<InsuranceAmount>18.45</InsuranceAmount>
<ShipDate>2012-02-28T01:09:42.000Z</ShipDate>
</Package>
<DeliveryAddress>
<Address>
<LastName>Eun Kyung Buyerperson</LastName>
<Address1>561 West 14777th Street Apt.22</Address1>
<City>New York</City>
<Country>US</Country>
<StateAsString>Unknown</StateAsString>
<CountryAsString>US</CountryAsString>
<PostalCode>10031</PostalCode>
<Phone>2017500000</Phone>
<EMail>11ka8rson@demo-email.net</EMail>
</Address>
</DeliveryAddress>
<ShipmentId>f6d1ee4c-1b43-4e00-97c8-a012010fef76</ShipmentId>
<ShipmentStatus>Unknown</ShipmentStatus>
<ShipmentType>Unknown</ShipmentType>
</Shipment>
<Order>
<ShipMethod>FedEx - Ground</ShipMethod>
<OrderId>5e50c680-d817-42b8-91be-############</OrderId>
<OrderDate>2012-02-28T01:09:42.000Z</OrderDate>
<ItemsTotal>18.45</ItemsTotal>
<Total>18.45</Total>
<ShippingChargesPaid>6.5</ShippingChargesPaid>
<ItemsTax>0</ItemsTax>
<OrderNumber>100003076</OrderNumber>
<ExternalID>100003076-2012-02-27 17:09:42</ExternalID>
<PaymentType>0</PaymentType>
<PaymentTypeAsString>0</PaymentTypeAsString>
<PaymentStatusAsString>0</PaymentStatusAsString>
<PaymentStatus>0</PaymentStatus>
<DocumentType>Unknown</DocumentType>
<ShipmentOrderItem>
<Weight>0</Weight>
<Sequence>0</Sequence>
<Name>"T" Tuning Wrench for Harpsichord, Zither, Dulcimer or Harp</Name>
<Price>11.95</Price>
<ExternalID>A-9</ExternalID>
<Quantity>1</Quantity>
<Total>11.95</Total>
</ShipmentOrderItem>
<BillingAddress>
<LastName>Eun Kyung Buyerperson</LastName>
<Address1>561 West 14777th Street Apt.22</Address1>
<City>New York</City>
<Country>US</Country>
<StateAsString>Unknown</StateAsString>
<CountryAsString>US</CountryAsString>
<PostalCode>10031</PostalCode>
<Phone>2017500000</Phone>
<EMail>11ka8rson@demo-email.net</EMail>
</BillingAddress>
<ShippingAddress>
<LastName>Eun Kyung Buyerperson</LastName>
<Address1>561 West 14777th Street Apt.22</Address1>
<City>New York</City>
<Country>US</Country>
<StateAsString>Unknown</StateAsString>
<CountryAsString>US</CountryAsString>
<PostalCode>10031</PostalCode>
<Phone>2017500000</Phone>
<EMail>11ka8rson@demo-email.net</EMail>
</ShippingAddress>
</Order>
</TShipTransaction>
</ShipTransactions>
</Data>
</Notification>Attribute |
Discussion |
<PaymentStatus> |
0 = Not Paid |
<ShipmentType> |
Ignore this, as it is for internal My.ShipRush use. Rather, refer to elements
|
Retries
Your server must return HTTP 200 for all processed notification. A non-200 response will trigger a retry for that user in the future. Retries will be every 5-20 minutes based on system load.
For cases where the developer system returns a non 200 response, it is strongly suggested that the developer log the full payload of the notification, as this may expose a problem in the developer system that is causing it to unintentionally reject notifications.
RemoveNotification() - Removes Configured Notifications
Be sure to review the note above.
This is how the developer can remove previously configured notifications. This functionality may be disabled if the notification settings are manually locked as described above.
Endpoint - RemoveNotification()
/accountservice.svc/notification/remove
Request - RemoveNotification()
Notification Type |
Type of Notification to remove. If this type is Unknown, them all configured notification for your developer token would be removed |
Sample
<?xml version="1.0" encoding="utf-8"?>
<RemoveNotificationRequest>
<NotificationType>Order</NotificationType>
</RemoveNotificationRequest>Response - RemoveNotification()
Returns empty response.
<RemoveNotificationResponse>
</RemoveNotificationResponse>GetNotificationStatus() - Returns All Configured Notifications
Be sure to review the note above.
This is how the developer can remove previously configures notification.
Endpoint - GetNotificationStatus()
/accountservice.svc/notification/status
Request - GetNotificationStatus()
Notification Type |
Type of Notification to return. If this type is Unknown, then all configured notification for your developer token would be returned. |
Sample
<?xml version="1.0" encoding="utf-8"?>
<GetNotificationStatusRequest>
<NotificationType>Order</NotificationType>
</GetNotificationStatusRequest>Response - GetNotificationStatus()
Returns list of configured notification for your developer token.
<GetNotificationStatusResponse>
<Notifications>
<NotificationConfiguration>
<URL>https://DeveloperSystem.com/shiprush/notification</URL>
<Enabled>true</Enabled>
<NotificationType>Order</NotificationType>
<AutosubscribeNewUsers>true</AutosubscribeNewUsers>
<DataFormat>XML</DataFormat>
<ApiVersion>43980</ApiVersion>
<Transform>false</Transform>
<ErrorMessage></ErrorMessage>
<NotificationConfiguration>
</Notifications>
</GetNotificationStatusResponse>SubscribeToNotification() - Subscribes to Notifications
Be sure to review the note above.
This is how the developer subscribes individual accounts to notifications. Only required if "AutosubscribeNewUsers" for the developer key set to FALSE or if you want to bulk-subscribe all of your customers and did not have AutoSubscribeNewUsers set TRUE when the users were created.
This functionality may be disabled if the notification settings are manually locked as described above.
Endpoint - SubscribeToNotification()
/accountservice.svc/notification/subscribe
Request - SubscribeToNotification()
AccountId |
(optional) If specified subscribes this account to data notifications; otherwise, all accounts are configured for developer token would be subscribed. |
SubscribeFrom |
(optional) If specified subscribes users from specified date. Useful for getting "old" orders (from few hours ago). The FROM must be within 48 hours of Now(). (All dates in My.ShipRush are ISO 8601 format. Always provide UTC values for input values. Output values will properly be tagged as UTC. For information: http://en.wikipedia.org/wiki/ISO_8601 ). |
NotificationType |
(optional) Notification payload type. Initially we plan to support "Order" only, which will send full shipment XML. Future options - ShipmentsIDs or date range for which data changes found. |
Sample
<?xml version="1.0" encoding="utf-8"?>
<SubscribeToNotificationRequest>
<AccountId>732dcc14-a010-4ba1-b318-###########</AccountId>
<NotificationType>Shipments</NotificationType>
</SubscribeToNotificationRequest>Response - SubscribeToNotification()
Returns empty response
Sample
<?xml version="1.0" encoding="utf-8"?>
<SubscribeToNotificationResponse>
</SubscribeToNotificationResponse>UnsubscribeFromNotification() - Unsubscribes from Notifications
Be sure to review the note above.
This functionality may be disabled if the notification settings are manually locked as described above.
Endpoint - UnsubscribeFromNotification()
/accountservice.svc/notification/unsubscribe
Request - UnsubscribeFromNotification()
AccountId |
(optional) If specified unsubscribes this account from data notifications, otherwise all accounts configured for developer token would be unsubscribed |
NotificationType |
(optional) If specified unsubscribes from this notificationType only, otherwise unsubscribes from all notifications |
Sample
<?xml version="1.0" encoding="utf-8"?>
<UnsubscribeFromNotificationRequest>
<AccountId>732dcc14-a010-4ba1-b318-###########</AccountId>
</UnsubscribeFromNotificationRequest>Response - UnsubscribeFromNotification()
Returns empty response
Sample
<?xml version="1.0" encoding="utf-8"?>
<UnsubscribeFromNotificationResponse>
</UnsubscribeFromNotificationResponse>GetSubscriptions() - Get List of Subscribed Account with Statuses
Be sure to review the note above.
Endpoint - GetSubscriptions()
/accountservice.svc/notification/getsubscriptions
Request - GetSubscriptions()
AccountId |
(optional) If specified gets status for this account, otherwise you get all configured account for developer token |
Sample
<?xml version="1.0" encoding="utf-8"?>
<GetSubscriptionsRequest>
</GetSubscriptionsRequest>Response - GetSubscriptions()
Returns status of requested users
Sample
<?xml version="1.0" encoding="utf-8"?>
<GetSubscriptionsResponse>
<Subscriptions>
<SubscriptionConfiguration>
<AccountId>732dcc14-a010-4ba1-b318-###########</AccountId>
<NotificationType>Order</NotificationType>
<Status>Success</Status>
<LastAttemptAt>2011-01-01T20:00:01</LastAttemptAt>
<LastSuccessAt>2011-01-01T20:00:01</LastSuccessAt>
<LastShipmentChangedAt>2011-01-01T15:00:00</LastShipmentChangedAt>
<ErrorMessage></ErrorMessage>
<Enabled>true</Enabled>
<Request>
<Headers></Headers>
</Request>
<Response>
<Headers></Headers>
</Response>
</SubscriptionConfiguration>
<SubscriptionConfiguration>
...
</SubscriptionConfiguration>
</Subscriptions>
</GetSubscriptionsResponse>GetSubscriptionStatistics() - Get Statistics for Specific Platform Notification
Be sure to review the note above.
Endpoint - GetSubscriptionStatistics()
/accountservice.svc/notification/getsubscriptionstratistics
Request - GetSubscriptionStatistics()
PlatformNotificationId |
(required) Platform Notification Id for requested statistics. |
Sample
<GetSubscriptionStatisticsRequest>
<PlatformNotificationId>7071e9c0-bea0-418d-bfec-############</PlatformNotificationId>
</GetSubscriptionStatisticsRequest>Response - GetSubscriptionStatistics()
This function returns 2 block of statistics (for last hour and last day) and list of last errors happened during last day for all subscriptions within requested platform notification.
Sample
<GetSubscriptionStatisticsResponse>
<LastHour>
<Processed>31</Processed>
<Successful>31</Successful>
<Failed>1</Failed>
<TotalObjectPushed>2497</TotalObjectPushed>
</LastHour>
<LastDay>
<Processed>728</Processed>
<Successful>728</Successful>
<Failed>1</Failed>
<TotalObjectPushed>58992</TotalObjectPushed>
</LastDay>
<LastErrors>
<SubscriptionError>
<SubscriptionId>90b68ce8-78c1-4aa6-a296-############</SubscriptionId>
<RunAt>2012-05-10T20:20:50</RunAt>
<ErrorMessage>Unable to POST 'https://someserver.com/pushing'. The remote server returned an error: (404) Not Found. </ErrorMessage>
</SubscriptionError>
</LastErrors>
</GetSubscriptionStatisticsResponse>FAQ
Q: I expect a notification but am not receiving one. What is up?
A: Check the Subscription -> Notification flow
Call GetSubscriptions() and pass in account ID (GetSubscriptionStatistics() may be useful). This can show you the error being thrown if there is one.
If no error, then take the Notification from the response above and pass into GetNotificationStatus(). Check that the endpoint is the one you expect.
B: Is there actually a subscription for the user?
Note that if the user is created before the notification is created, the user will not have a subscription connecting the user to the notification. (No subscription.... no data!).
Use SubscribeToNotification() to subscribe a user to a notification.
Then use GetSubscriptions() to confirm the subscription is correct.
Q: How Can I Test that My System Can Properly Accept the Gzip POST from My.ShipRush?
Using Curl
Fiddler is the right tool to test without gzipping the payload. To gzip, curl is needed. This can be done on Windows, Linux or any OS (curl is available from http://curl.haxx.se/ ).
Create an XML payload that your system can accept
Save it to a file, say: payload.xml
-
Use this curl syntax to push payload XML onto your receiving endpoing
curl --header "Content-Type: application/xml" --data-ascii "@payload.xml" https://<yourendpoint> --insecure --trace-ascii -
Note: The "–insecure" tag is only needed in some cases when posting to HTTPS. If posting to HTTP, it is not needed
Work on your system until the curl call works and receives a 200 response
Now gzip payload.xml (use 7-Zip or another tool that can create a gzip file). Call the file: payload.xml.gz
-
Use this syntax
curl --header "Content-Type: application/xml" --header "Content-Encoding: gzip" --data-binary "@payload.xml.gz" https://<yourendpoint> --insecure --trace-ascii -
Work on your system until the curl call works and receives a 200 response
Using Fiddler
Fiddler is great for non gzip POST operations. The following, not tested by Z-Firm, is from the author of Fiddler. It explains how to do a gzipped POST from Fiddler. (This should be validated using http://posttestserver.com or similar!)
Be sure to use the current version of Fiddler.
Second, it's important to understand that most of Fiddler's visible compression features relate to the compression of the response rather than of the request. That's because many/most servers don't support compression of requests because browsers don't have any way to know a priori whether it will be supported and hence browsers don't compress requests. Similarly, supporting compressed requests opens the server up to ZIP-bomb attacks.
Now, having said that, some servers do support compressed requests, and Fiddler can generate these. The first question is "How are you generating your request?"
If you're using the Composer, do this: Click Rules > Customize Rules. Scroll to OnBeforeRequest. Add the following lines:
static function OnBeforeRequest(oSession: Session) { if (oSession.oRequest.headers.ExistsAndContains("Content-Encoding", "doGZIP"))
{ oSession.oRequest.headers.Remove("Content-Encoding"); oSession.utilGZIPRequest(); }Q: What Triggers a Push? I am Fiddling with the Order in SR Web, but it is not Getting Re Pushed to My Endpoint.
A: Only certain changes to an order will trigger a push. Those changes are:
new order imported
paid status changes paid/unpaid
cancelled status changes not-cancelled-> cancelled
shipped status changes: shipped/not shipped
Other miscellaneous changes will not trigger a push.