Order Notifications

The Neto Order Notifications API is an optional call to an external webhook in response to order change events occurring in the Neto e-Commerce Suite. The Notifications API response will include the webstore's webhook verification key and optional signature headers so your application can ensure the call is coming from Neto and has not been tampered with.

Turn on Order Notifications

From your Neto control panel, navigate to: Settings & Tools > All Settings & Tools > API Settings. If this is the first time setting up your webhook, regenerate a new Webhook Verify Token then tick the Enable Maropost API webhook checkbox. Finally, enter your applications Webhook Endpoint (where you want to be notified about order events) as the Maropost API webhook URL and click Save Changes.

Neto will now trigger an order notification whenever an order event occurs. See below for a full list of order events.

Verify webhook source

As an additional securely measure, Neto can send a webhook signature with the response. Your application can then verify this signature using the provided RSA public key to ensure the webhook notification is authentic.

From your Neto control panel API Settings download your Webhook RSA Public Key. If this is the first time setting up webhook verification, click Regenerate Key Pair to create a new RSA public key.

With the RSA key generated, Neto will send two additional headers with the webhook response. One with the webstore Store ID and one with the verification signature. If an error occurred generating the signature an error header will be provided instead. If this occurs, regenerate the key pair in your API Settings and download the public key again.

If you are building out a bespoke application for a single store, grab the webhook verify key and RSA public key. You should already have a staff level API Key as well. For security reasons, never use the stores Global API Key in a production setting.

If you are an integrator you will need to request these details while onboarding. If your application runs through the Neto OAuth flow you do not need personal API Keys for each store, just the webhook verify key and RSA public key.

When your application receives a webhook response, check the headers for the verify key, store id, and signature. The verify key will be an exact match to what is stored in the stores control panel. If it is not, do not process the webhook notification and ask the merchant to regenerate a new verify key.

The store id will be the stores API ID value you received from the Neto OAuth flow. Or if you are not using OAuth, it will be the Store Hash value at the bottom of any control panel page. With this value provided, you no longer need a webhook route for every merchant using your application. Instead you can provide a single route and just check the store id.

Finally the signature is a Base64 encoded version of the webhook body, using the stores matching RSA private key. To verify the signature, take the webhook body you received then minify and SHA256 hash it before running it through a function that checks the hashed data against the signature and RSA public key. Most server side languages should have a built in module for this, such as the Node crypto.verify(algorithm, data, publicKey, signature) function.

function verifyWebhook(
  data: string,
  signature: string,
  publicKey: string
): boolean {
  const dataBuffer = Buffer.from(minifyXML(data));
  const signatureBuffer = Buffer.from(signature, 'base64');
  const isVerified = crypto.verify(
    'sha256',
    dataBuffer,
    {
        key: publicKey,
        padding: crypto.constants.RSA_PKCS1_PADDING
    },
    signatureBuffer
  );
  return isVerified;
}

If the webhook cannot be validated, do not process it, instead ask the merchant to regenerate the RSA key pair and provide the new public key. If you believe the webhook notification is valid, ensure your application is minifying the whole XML response body and providing that as the data to verify along with the signature and public key.

Practical Uses

You can use the Notification API to notify your application of new orders or changes to an existing orders. On receipt of a notification you can then use other API calls such as GetOrder or UpdateOrder to perform a desired action. Using the Notification API can help to reduce the number of unnecessary calls you make to the application looking for a particular order event.

Notifications are sent as XML via POST to your specified URL.

Example Notification

Order status changed to 'Pick'.

<?xml version="1.0" encoding="utf-8"?>
<Event>
  <CurrentTime>2026-01-03 01:11:12</CurrentTime>
  <EventID>34</EventID>
  <EventType>Order</EventType>
  <Order>
    <OrderID>N10154</OrderID>
    <OrderStatus>Pick</OrderStatus>
  </Order>
</Event>

Order created in Neto POS

<?xml version="1.0" encoding="utf-8"?>
<Event>
    <CurrentTime>2026-01-03 02:41:40</CurrentTime>
    <EventID>35</EventID>
    <EventType>Order</EventType>
    <EventSubtype>OrderCreated</EventSubtype>
    <Order>
        <OrderID>POS01-27</OrderID>
        <OrderCreated>Dispatched</OrderCreated>
    </Order>
</Event>

Order approved

<?xml version="1.0" encoding="utf-8"?>
<Event>
    <CurrentTime>2026-01-03 04:33:12</CurrentTime>
    <EventID>36</EventID>
    <EventType>Order</EventType>
    <EventSubtype>OrderApproved</EventSubtype>
    <Order>
        <OrderID>N10155</OrderID>
        <OrderApproved>Approved</OrderApproved>
    </Order>
</Event>

Order updated

<?xml version="1.0" encoding="utf-8"?>
<Event>
    <CurrentTime>2026-01-03 06:02:43</CurrentTime>
    <EventID>37</EventID>
    <EventType>Order</EventType>
    <EventSubtype>OrderUpdated</EventSubtype>
    <Order>
        <OrderID>N10156</OrderID>
        <OrderUpdated>Order updated</OrderUpdated>
    </Order>
</Event>

Shipping added

<?xml version="1.0" encoding="utf-8"?>
<Event>
    <CurrentTime>2026-01-03 08:42:07</CurrentTime>
    <EventID>38</EventID>
    <EventType>Order</EventType>
    <EventSubtype>ShipmentAdded</EventSubtype>
    <Order>
        <OrderID>N10157</OrderID>
        <ShipmentAdded>Shipment created</ShipmentAdded>
    </Order>
</Event>

Payment updated

<?xml version="1.0" encoding="utf-8"?>
<Event>
    <CurrentTime>2026-01-03 09:12:56</CurrentTime>
    <EventID>39</EventID>
    <EventType>Order</EventType>
    <EventSubtype>PaymentUpdated</EventSubtype>
    <Order>
        <OrderID>N10158</OrderID>
        <PaymentUpdated>Order fully paid</PaymentUpdated>
    </Order>
</Event>

Notification Structure

Webhook event priority

All webhook events are independently triggered, meaning the platform does not pick one event notification over another. If an order action triggers multiple order events, your application will get multiple notifications for the same order.

The exception is the OrderUpdate event, which is suppressed if a more specific order event has already triggered. For example an UpdateOrder API call that changes the order status and adds tracking will trigger both an OrderStatus and ShipmentAdded event, but not an OrderUpdate event.

Integrator checklist

• Ensure your application does not use the stores Global API Key in a production setting. You should either run through the Neto OAuth flow to be granted access, or have a personal API Key provided to you from the merchant.
• Ensure you verify the webhook before performing any update actions.
• When subscribing to webhook events, ensure your application is checking the EventType and EventSubtype. If EventSubtype is missing, treat this as an OrderStatus event (subtype omitted in this case to help with backwards compatibility).
• Do not assume an order is unapproved until you receive an OrderApproved event. This event only triggers for manual approvals and not for orders the control panel or API automatically approve.
• Do not assume every order triggers an OrderCreated event. This event only triggers for new Neto POS orders.

Valid Response

If the call to your webhook is successful, your application should respond “200 OK”. If your application makes no response or provides any other response, Neto will treat the notification as undelivered, and delivery will be optionally reattempted at a later time. Check your API Webhook Retry Schedule Task settings to confirm your webstore setup.