Changelog
Updates Developer Center
Changelog 2026
Effective 1 July 2026, the service Shipment and Return label will be phased out. From this date onward, it will no longer be possible to create this shipment type via the API.
Within the API payload, this service is identified by:
"ProductOptions": [{|"Characteristic": "152","Option": "026"}]
What will changeAs of 1 July 2026, any new shipment request containing Characteristic 152 with Option 026 will result in an error response.
Shipments manifested before 1 July 2026 using this service remain eligible for return until 1 August 2026.
After 1 August 2026, these return parcels presented at PostNL retail locations will be refused, as acceptance and processing are no longer supported.
Integration impactAfter 1 August 2026, each return shipment must be manifested as a new return shipment with a newly generated barcode. Reuse of the original Shipment and Return barcode will no longer be supported.
Integrations that explicitly include Characteristic 152 / Option 026 must be updated before 1 July 2026 to prevent production errors and rejected shipment requests.
Discontinuation of activate return endpointAs part of the phase-out of the Shipment and Return label, the associated activate return endpoint will be discontinued.
POST api.postnl.nl/parcels/v1/shipment/activatereturn
This endpoint is used to remove a handover blockade applied to a Shipment and Return label. The blockade is configured during pre-announcement by including the following product option:
"ProductOptions": [{"Characteristic": “191","Option": “004"}]
Effective 1 August 2026, calls to this endpoint will no longer be accepted. Requests will result in an error response.
From that date onward, it will no longer be possible to activate or unblock returns for Shipment and Return labels via the API.
Do you need help?For questions or support, please submit a case here to contact the Channel Integrations team.
Effective date: 12 May 2026
Scope: Labelling API and Confirming API
SummaryTo ensure stable and predictable API performance, a strict limit of 25 shipments per request will be enforced. Requests exceeding this limit will be rejected.
ContextSome integrations currently submit large multi-shipment requests in a single call. These requests consume a disproportionate share of backend resources, leading to increased latency and timeouts that affect other consumers.
Enforcing a fixed upper limit per request reduces resource contention, prevents cascading performance degradation, and ensures fair and consistent service levels across all API consumers.
What is changing
- Maximum of 25 shipments per API request
- Requests exceeding this limit will be rejected
Required actions
- Ensure no API request contains more than 25 shipments
- Update batching logic where large volumes are currently sent in a single call
- Monitor integrations after 12 May to detect and resolve rejected requests
SupportFor questions or assistance, contact the Channel Integrations team by submitting a case here.
Starting from April 1st we will return combilabels instead of singel labels for destination France for product code 4907 (parcels EU). It could be that based on the weight or size of the parcel we determine to relabel to another partner carrier in our sorting process.
Other than the changing label lay-out there is no impact.
From now on it’s no longer needed to create an international barcode via the Barcode API. Instead, you can directly request a label without barcode in order for PostNL to create a correct barcode for you. The created barcodes will be given back via the API response of the Labelling and Shipping/Shipment APIs. This is supported for both the V2 and V4 APIs.
For V2 API’s it’s not mandatory to make use of this new functionality. For V4 API’s requesting an international barcode via the Barcode API will no longer be supported.
When making use of automated barcode generation via the Labelling and Shipping/Shipment, be aware that the first two letters of the barcode will be different from the current barcode types as can be seen in table below.
| Barcode service type | Type when using barcode API | Type when PostNL creates barcode via labelrequest |
Untracked international letterbox & packet | UE | UL, UM |
Tracked international letterbox & packet | LA | LW |
Registered international letter | RI | RF |
| Parcel ROW | Starting with C | CW |
Impact on parcel ROW
Please also note that when using the automated barcode generation for parcel ROW, it’s no longer needed to use your customer specific Type (for example CL) and Range (for example 1234). Be aware that if you make use of the shipping status API that the ‘Barcode method’ will not support the new automated generated barcodes. Instead, you will need to use the ‘Reference method’ in order to retrieve tracking information on shipment level.
Because of a simplification in our international product portfolio, a lot of contract specific product codes from the international product portfolio have been phased out since February 25th 2026.
The new product codes will offer the exact same service, label and rates.
Changerequest:
In order to change the productcode please check your V2 configuration for: Shipping, Labelling and Confirming,
In these requests the product code ( in the API known as "ProductCodeDelivery” ) must be changed according to schedule below. Apart from the "ProductCodeDelivery” the rest of the request can remain the same.
It’s optional to not request and provide a barcode in the shipment request. In that case a barcode will be created by PostNL, starting with RF.
| Product name | Phased out per February 25th "ProductCodeDelivery” | New "ProductCodeDelivery” |
| Registered international letter |
|
|
From 24 February 2026, Delivery Code shipments with a PO box (postbusnummer) as the receiver address will no longer be creatable via our IT-solutions.
The Delivery Code service requires the physical presence of the receiver to provide the verification code that serves as proof of delivery. PO boxes are unmanned and follow a different handover process, which means this code cannot be reliably entered or verified. As a result, delivery cannot be completed for these shipments.
To prevent undeliverable shipments from entering the network, validation will be enforced across all versions of the Labelling, Confirming, and Shipment APIs.
Current behaviour
Requests for Delivery Code shipments addressed to PO boxes succeed (200 OK). A shipment label is created and the shipment is manifested.
New behaviour (effective 24 February 2026)
Requests for Delivery Code shipments addressed to PO boxes will fail with 400 Bad Request. The following error message will be returned:
“Receiver address cannot be a postal box”
Action required
- Validate receiver addresses before creating Delivery Code shipments.
- Update any integration logic that allows PO box addresses for this service.
Do you need help?
For questions or support, please contact the Channel Integrations team via Need help? Submit a case | PostNL.
Changelog 2025
Due to changing regulations from the UPU (Universal Postal Union) from 2026 onwards it’s no longer allowed to ship registered packets and letterbox parcels containing goods to destinations outside of the Netherlands.
This concerns the following product codes:
6906
6908
Both products will bel continued by PostNL as a tracked service including insurance up to 50 euro.
Technical impact:
In order to comply with the new regulations and still use the same product code we ask customers to do the following.
Currently a registered barcode (starting with RI) is required for these international packets. This must be changed to a tracked barcode (starting with LA).
To do so you must change the parameter “Type” in the Barcode API from “RI” to “LA” in your barcode request. The rest of the barcode request can remain the same.
Example of a correct barcode request: https://api.postnl.nl/shipment/v1_1/barcode?CustomerCode=ABCD&CustomerNumber=11223344&Type=LA&Serie=00000000-99999999&Range=NL
The new barcode can be used with immediate effect. It’s recommended to change your configuration as soon as possible as countries may decide not to process packets with RI barcodes anymore in 2026.
For registered international letters not containing goods (product code 6418) RI barcodes must still be used.
Shipping to the United States and several US overseas territories is now available again. For shipments to the US and Puerto Rico (PR), new import regulations apply:
A customs declaration and import duties are now required for all shipments, regardless of value.
You’ll need to sign a contract addendum authorizing PostNL to prepay duties and invoice you later.
Validation for these destinations is stricter: always include a 10-digit HS code and complete customs data to avoid errors or extra costs.
For other US territories such as American Samoa (AS) and Guam (GU), the new rules do not apply. You can continue shipping there as usual — just make sure to select the correct country code (not US) when creating your shipment.
Read the full instructions and request the contract addendum to activate shipping to the US and Puerto Rico.
As of January 2026, the module where you manage your API keys will switch to a new portal. Make sure to store your current API key safely, if you haven’t done so yet, as it will no longer be visible after this date. In the new portal, you’ll be able to request and manage your API keys for our future-proof APIs.
15.04.2026 - Update: this change has been post-poned until further notice, we will communicate the planned date as soon as possible.
Due to the new regulations in the United States, it is temporarily not possible to send parcels and packets to the United States via PostNL. We are working on a solution. Business mail (documents in an envelope) can still be sent.
[18-08-2025] Urgent: Changing Regulations for shipping goods to the United States
As of August 29, increased import duties and taxes must be paid for shipments to the US. Following this change, it becomes even more important to provide correct customs data when pre-registering shipments.
Validation change per August 22th
In preparation for this change, PostNL requires from August 22 onwardsthat HS codes (HSTariffNr) must contain 10 digits for shipments to the US (CountryCode = US).
From August 22 onwards an error message will be returned if a HS-code is longer or shorter than 10 digits.
Valid HS codes can be found at: https://dataweb.usitc.gov/tariff/database
The US has threatened that high costs may be charged to the sender for incomplete customs declarations. Therefore, we strongly urge you to also pay close attention to the accuracy of other customs data, such as:
- The value of the goods
- A clear description of the goods
- The country of origin of the goods (This must be the country where the product was manufactured or substantially processed)
For other destinations outside the EU, the current rule remains that HS codes must contain 6-10 digits.
We are currently working on a new Delivery Duty Paid solution for the US. This might lead to additional requirements for destination US. We will keep you posted about this via our developer portal.
[11-06-2025] Action Required: Enforced ContactType Validation
Starting June 12, 2025, all versions of these APIs will enforce a validation rule allowing only one contact with type "01" in the Contacts object. If multiple "ContactType": "01" entries are sent, an error will be raised with either errorcode 34019 or 340209,
Action:Review your integration and ensure only one "ContactType": "01" is included per shipment.
Support:For questions or support, please contact the Channel Integrations team via: https://developer.postnl.nl/support/form/
We are renewing and improving our API portfolio to make your integration with PostNL easier, more secure, and future-proof. These new versions improve performance, provide more consistency, and are better aligned with modern systems and data models. We’re also implementing API Life Cycle Management, making updates more predictable and easier to manage. The new APIs will be rolled out in phases. The Shipment API v4 and the all-new Returns API v4 will be the first, going live in May 2025.
Please be informed that the ERS products for our international return solutions will be unavailable on April due to scheduled maintenance between 07:00 AM and 11:00 AM on Tuesday April 29. Be advised that this applies for the ERS Portal & the ERS products via API.
We apologize for any inconvenience this may cause.
Starting March 13th, we are implementing technical upgrades for international shipments processed through our partner, DPD. These enhancements may result in different pre-alert error messages than those previously encountered. The error messages will indicate what the issue is.
Change:
From April 17, 2025, PostNL will update the Labelling-API, Confirming-API, and Shipment-API (all versions). Additional pre-announcements on barcodes that have received an acceptance scan (B01) will be rejected. Modifications to parcels already in process will no longer be possible.
Impact:
- Additional label creation: Once a parcel has received its first logistical scan by PostNL, no additional labels can be generated.
- Pre-announcement scheduling: Pre-alert modifications must be completed before handover to PostNL, as updates will no longer be allowed after an acceptance scan.
Action Required:
- Ensure all pre-announcements are completed
- Update integrations to prevent duplicate or late pre-alerts.
Support:For questions or assistance, contact the Channel Integrations team via the support form.
As of February 2, Sunday Delivery and 08:00-09:00 Delivery are no longer available. On March 2, Today Delivery will also be discontinued. Affected APIs include Timeframe, Checkout, DeliveryDate, Labelling, Shipment, and Confirming.
From March 17, the parameters Sunday, 08:00-09:00, and Today will no longer be usable, and API calls with these will return an error. Update your integration to avoid disruptions.
Per January 1st, one extra observation scan is added to our Shipping Status API. The observation scan has to do with the new postal regulations in Germany we communicated about earlier. Per January 1st all items shipped to Germany with a weight higher than 10KG should include a weight icon on the label. The icon placed on the label is based on the pre-announced weight. If you ship an item of 12KG, but pre-announce it with a weight lower than 10KG or no weight at all, it’s necessary for us to relabel the parcel again before shipping it to Germany. As a result of relabeling the partner barcode on the combilabel will be replaced as well. The original partner barcode becomes obsolete.
To prevent this behavior we strongly recommend to fill in a correct weight when pre-announcing shipments to Germany. If you’re not able to do so (and do ship items above 10KG) we strongly recommend not to build any (track and trace) logic on the partner barcode (DownPartnerBarcode).
T&T status code / Observation: P12
Description: NL: “Onjuiste gegevens, labelcorrectie volgt. Gebruik alleen de originele (3S) track & trace-code.” / ENG “Shipment to be relabeled due to incorrect data. Please use the original (3S) tracking code only.”
Explanation: This scan observation indicates that the international combilabel and partner barcode will be replaced.
We recommend treating this observation as an indicator to correctly pre-announce weights in the future.
Changelog 2024
On October 30, we will implement a change in the ZPL output of Zebra printers for international labels. The ZPL output will include the command ^LH0,0. This command ensures the correct alignment of the label. Additionally, we will remove the command ^MD30 from the ZPL output. This command was responsible for darkening the label output but did not always have the desired effect.
Per 4th September 2024, two extra scan observations are added to the most common SFTP connection. These scan observations provide more insight into when a shipment is delayed during peak periods. This gives you the opportunity to proactively inform recipients or answer their questions. Below an explanation of the extra scans.
T&T status code / Observation: G03
Description: NL: “Door drukte duurt de bezorging wat langer dan normaal. We bezorgen je pakket zo snel mogelijk.” / ENG “It's very busy. Please allow for slightly slower delivery times. We'll deliver your parcel as soon as we can.”
Explanation: This scan observation indicates that a shipment that has been handed over at a PostNL drop-off point is not yet sorted and is currently in stock waiting for the first sorting scan.
We recommend to treat this observation as an indication that the parcel is delayed.
T&T status code / Observation: V06
Description: NL “Door drukte duurt de bezorging wat langer dan normaal. We bezorgen je pakket zo snel mogelijk.” / ENG “It's very busy. Please allow for slightly slower delivery times. We'll deliver your parcel as soon as we can.”
Explanation: This scan observation also indicates a delay. It did not receive its first sorting scan yet. This scan often occurs during peak periods. We recommend to treat this observation as an indication that the parcel is delayed.
How can you act on this change?
Prepare for this change by storing the codes (G03 and V06) and corresponding descriptions in the appropriate (harmonization or definition) table. Check the complete list of PostNL T&T status codes. In addition, make sure that applications that convert the scan observations to information for your business processes recognize these scans and provide the correct information.
Please be informed that all PostNL-API's necessary for the creation of shipping-labels and pre-alerts will be unavailable due to scheduled maintenance between 01:00 AM and 02:00 AM (CET) on July 2nd. Be advised that this also applies to the Shipment-API.
Please be informed that all PostNL-API's necessary for the creation of shipping-labels and pre-alerts will be unavailable due to scheduled maintenance between 01:00 AM and 01:30 AM on June 25th. Be advised that this also applies to the Shipment-API.
We apologize for any inconvenience this may cause.
On Wednesday, May 22, from 21:00-22:00, both the Labelling and Shipment APIs will undergo maintenance to address the incorrect handling of multiple shipment objects in one API-call. No downtime is expected for either service.
On June 18, 2024, we will implement a new validation process for business reply numbers related to product codes 2285 and 3285, which will affect return shipments. This update is crucial to ensure accurate preannouncements and improve both billing and product quality.
Validation Activation:
- For product code 2285, only business reply numbers can be used as recipient addresses.
- For product code 3285, business reply numbers cannot be used as recipient addresses.
Impact:
- This change has no impact if preannouncements are correct
- Incorrect preannouncements will trigger an error.
- Affected shipments will not receive a label or be pre-notified.
Required Actions:
If needed, adjust the recipient's address in AddressType 01 to align with the correct product code requirements.
Support:
- For API adjustments or testing, contact us via the support form with "Business reply number validation" in the subject.
- If you would like advice on which product codes or return options to use, please contact your account manager.This update is part of our ongoing effort to enhance service accuracy and efficiency.
Per 10 april 09:00 AM, the application for the generation of shipping labels will be upgraded. As a result, Printertype-responses in the categy Zebra|Generic ZPL II have adjustments in the buildup of the ZPL-code. Users of this printer type output are advised to evaluate the ZPL-output on compatibility with application(s) and/or hardware.
Adjustments to the ZPL output are as follows:
- The resolution command (^JM) is now set within a label format (^XA, ^XZ block)
- The documentation command (^FX) containing the form name is no longer generated.
- The ZPL header value in the default configuration file was changed to an empty value instead of "^MMT". If the original value (^MMT) is used, it is replaced by "^XA^MMT^XZ" to match the ZPL reference.
- Some ZPL commands like (^LS, ^LT etc.) are now generated only once before the first label and no longer on every label.
The new Zebra|Generic output-types are retrievable via the sandbox-environment of either Labelling- or Shipment-API.
Per January 10th, the API-management portal has been deactivated and can no longer be used for retrieving your API-credentials. Please contact Chanel integrations via the support form and provide your customer number and username of the API-management portal for assistance.
If you use the API key for Data Solutions and you are unable to locate your API key in the module 'Manage API keys', please reach out to our support team at datasolutions@postnl.nl.
Changelog 2023
It's time to take action if you are still using a version lower than 5.0.0 of the PostNL plugin for WooCommerce. The outdated versions will be disabled starting from November 1, 2023. How do I install the latest version?
First, close your existing orders. Please close all existing orders before installing the new plugin. If this step is omitted, shipping labels for these orders will not be generated. If you forget to do this, you can manually create the shipping labels later through your My PostNL environment.
The installation steps for the latest version can be found in the guide. Make sure to have your PostNL customer number and API details ready beforehand. Please note that the API details are different from what you are currently using. You can find these in your My PostNL environment under "My Account > Manage API."
Need assistance? Feel free to ask your question via the support form
You will receive a response within two business days.
On 01-01-2024 PostNL will launch a new product portfolio for sending from Belgium to the Netherlands. For customers this implies some technical changes in confirming shipments. These changes must be implemented between August 1st 2023 and January 1st 2024. During this period both the old and the new portfolio can be use
For more information, please visit this page where you will find all technical instructions for each of our IT connections.
PostNL has introduced a new portal for technical API documentation. This new website is based on the OpenAPI specification of our collection of API's for e-commerce processes. Via https://docs.api.postnl.nl you can find an easy-to-navigate documentation portal extended with up-to-date API specifications, references and code samples.
From now on PostNl offers a three-panel, responsive layout for the technical documentation:
• The left panel contains a search bar and navigation menu.
• The central panel contains the documentation.
• The right panel contains request and response examples.
The current Developer Portal will still be the entry point for information about the APIs for commercial information. Commercial information such as explanation of API usage and Use cases are still listed here. On the updated documentation pages, developers are now redirected to the technical documentation.
The renewed international product portfolio is available per the 1st January 2023. This makes it possible to select additional services per product. The choice of services offers you extra flexibility. You can easily choose per item which service you require. Do you send valuable items? Then you can choose to send the item with an insurance. Or do you prefer a cheaper option? Simply turn off the proof of delivery (signature) for that item.
New product codes have been added and the ‘old’ product codes can still be used until further notice. The renewed International product portfolio has been added to the responses of the most recent versions of the Shipping and Labelling API. Please note preferable method is via REST (JSON).
Take a look at the Productinformation | Parcel EU, Parcel Non EU and International Mail & Packets of the API’s for more information. Example requests are also available in the postman collection.More information about the portfolio can be found on our website
Changelog 2022
PostNL introduces sustainable delivery options. Today, more and more consumers find sustainable delivery important. By using our Delivery Options API’s you can show customers when their parcel can be delivered sustainably – right in the checkout of your webshop. That way, your customers can make a conscious choice for green delivery.
This sustainable options has been added to the responses of the most recent versions of the Checkout, Location and Timeframe API. Please note that this is only available in REST (JSON).
Take a look at the Documentation | Guidelines pages of the API’s for more information.
THE PLANNED DEPLOYMENT OF JULY 28 WAS CANCELLED AND POSTPONED TO AUGUST 18.
PostNL will improve the backend service of the Labelling 2.1 API. Though customers should not experience any service interrupting changes, this could affect custom implementations.
Our current backend returns plain ZPL code, which allowed for the manipulation of the ZPL code. Though this was not a functionality supported by PostNL, we have found that there are some customers who do this. The new backend returns the label as an image, rather than sending separate fields and codes, which means previously used manipulations of the ZPL output is no longer supported. This is done so that there is a more general adoption of different Zebra printers. Previously we needed to have separate drivers for different printers, this is no longer needed.
Due to the fact that we support special characters (UTF-8) and some technical reasons, the size of the labels has increased.
The updated backend service is already active in our test environment (and in the Labelling 2.2 and Shipping v1 version). If you are not sure whether this affects your PostNL integration, you can test this in the sandbox environment.
The updated shipments method returns all the updated statuses for a particular customer number in a specific period. Lately, we are increasingly confronted with the incorrect use of this method, which affects the overall performance of our platform and the performance of the API users.
It is best practice to request the updated statuses for a particular customer number in windows of 15 minutes. If needed, you can increase or decrease the frequency. For a useful result and a better performance, the maximum time window is 1 day. It is advisable to request a maximum period of 1 day.
To truncate search queries to the Shippingstatus API, our development team change to return an error if the requested time range exceed the maximum time window of 2 days.
PostNL stops its food network. The market has developed differently than expected, so PostNL is closing the network.
The productcodes are no longer displayed at the Products page.
As of April 1st 2022 the International product ‘Parcels Non EU – combilabel’ productcode 4947 should no longer be used. Shipments to destinations outside the EU can be send via the product ‘Parcels non EU – Single label’ productcode 4945.
Benefits of the ‘Parcels non EU – single label’ product are that it contains a single Internationally recognized S10 barcode. Instead of an S10 barcode and a domestic 3S barcode. This makes the API request easier because only the S10 barcode is sufficient for requesting tracking, labels and the use of shippingstatus webservice. A single barcode on an item improves quality and the tracking of International shipments.
For more information contact your Account Manager.
Changelog 2021
-
Changelog 2020
As of January 1st, 2021, we have a renewed product portfolio for parcels shipping to Belgium. If you are using any of the Parcels EU product codes for sending to Belgium, change the product code for shipments to Belgium to a Parcels Netherlands-Belgium product code in your confirming and/or labelling requests.
Please make sure you use the Parcels Netherlands-Belgium before January 1st, 2022. As of the 1st of May pre-announcements on the old product codes (4944, 4940, 4932, 4938, 4950, 4952, 4985, 4993 and 4996) for destination Belgium trigger a surcharge for pre-announcing incorrectly.
For more information, please visit this page where you will find all technical instructions for each of our IT connections.
Brexit is about to happen, which will impact postal and parcel movements towards the United Kingdom (UK). We would like to inform you on this, since there are technical changes required to keep on servicing our mutual customers.
From January 1, 2021, free movement of goods between the UK and the Netherlands will be restricted, and a customs declaration will be required. Via PostNL you will be able to digitally prepare shipments via the same method as currently is available for Parcels towards a non-EU destination.
The UK will be covered by our Parcel non-EU product after Brexit. For Packets, the product code will remain the same.
Technical changes are described on our Developer Center. As time moves on, Brexit impact becomes more clear and we will update our Developer Center accordingly. Please check the Brexit page.
From May 18 the EU countries Malta, Cyprus and Croatia will be classified as EU countries. This change takes place in our systems so if you have an PostNL integration you have to change this in your (shipping) system.
As of May 18th, Croatia, Cyprus and Malta will be covered by product 4944 (Parcels EU – formerly known as EPS), instead of 4945 (Parcels non-EU – formerly known as Globalpack). Label requests via API for these countries dated May 18th and later will result in an error.
A letter from the receiving sorting center will be printed on the label of Mailbox parcels (Brievenbuspakjes). In this way, customers and PostNL employees within the operation can more quickly see to which sorting center the package should be sent.
The letter appears on the label of you use the Labelling 2.2 or Shipping v1 API. If you are not yet using one of this webservices, the advise is to update/upgrade as soon as possible.
Letter A Amsterdam
Letter R Rotterdam
Letter H 's Hertogen Bosch
Letter N Nieuwegein
Letter Z Zwolle
-An validation has been added on the Shipment.Customs.Content.Content.Weight attribute. According to the documentation this already had to be an integer; this is now being enforced.
-For International shipments (EU and Rest of Word), a validation for a maximum weight in the Shipment.Dimension.Weight attirbute has been added. This is now at 999 kg for now. This can be adjusted in the future to guarantee that we can process the shipments.
Changelog 2019
It will soon no longer be possible to use the Cash on Delivery product codes. PostNL has decided to stop the cash on delivery service (rembours) in the Netherlands and Belgium from January 1, 2020.
The following product codes have been removed from the Product documentation page:
3086 COD
3091 COD + Extra cover
3093 COD + Return when not home
3097 COD + Extra cover + Return when not home
Belgium productcodes
4964 Belgium COD + Return when not home
4966 Belgium COD + Extra cover + Return when not home
PostNL has created its own retail network in Belgium. The cooperation with Kariboo therefore will be canceled from 1 December. From this date, no Kariboo points will be returned in the Location API response.The Kariboo network code (LN-01) can therefore no longer be used in the Labeling and Confirming API. The network code (DownPartnerID for Labelling API request) for Belgium will be PNPBE-01 from now on.
PostNL is sending technical information nowadays. With this bi monthly newsletter PostNL inform tech savvy customers through API updates, integrated services, Tips & Tricks, new functions, plugins and partner channels. Also useful information about new functionalities in MyPostnl and the Developer Center can be read in this newsletters.
You can subscribe here for this newsletter.
Archive newsletter:
June 2019
Augustus 2019
A beta version of the Check-out API is released. Combining the existing Timeframe, DeliveryDate, and Location APIs, it allows for quick and easy implementation of the PostNL delivery options while also reducing the risk of errors creeping in. For more on the new API, head over to the Checkout API.
Unfortunately the delivery option Early Morning Pickup Points is no longer viable. This delivery option (code PGE) is not an option anymore in the Checkout and Location API. This option will therefore disappear completely from 1 October 2019.
The option "Pick up at a PostNL location' remains unchanged as a service.
From now on it is temporarily no longer possible to offer Evening delivery in Belgium. This delivery option is not an option anymore in the Checkout, Deliverdate and Timeframes API's and therefore not be shown in this API responses.
We will inform you in time when the delivery option is reactivated.
From now on it is possible to run Parcels API Collection(s) directly in the Postman application. Postman helps you test and implement the Parcels API’s faster. The collections contains SOAP and JSON requests, are grouped together and organized into folders. The Postman collections are subdivided into the following groups: All, Shipping, Delivery Options and Track & Trace.
A new way of confirming the product Pickup Basic (Afhaalservice Basis) has been introduced. The new way of confirming is live on the 1st of June. The currrent way of confirming can be used until the 1st of July.
It is a small adjustment, you can find the new product specifications and see the guidelines of the Confirming API.
A new version of the Shippingstatus API (v2) has been introduced. This version is only available in REST (JSON).
The method Updatedshipments has been added to the interface; this method returns the updated statuses for a particular customer number.
New versions of the Labelling (v2.2) and Confirming (v2) have been introduced. Please check the Versioning paragraphs of the API's to see what have been changed compared to the previous versions.
A new API has been introduced to validate address data while it is entered.
Free* API for use in webshop checkout.
Please check the documentation for more information.
*Only free of charge for PostNL Parcels contract customers.
A new Belgium retailnetwork has been added to the services. The attribute DownPartnerID for Pickup at PostNL location can now contain the value PNPBE-01 in addition to the already existing code LN-01. Please check the Labelling and/or Confirming API documentation for more information.