0.9.0

The first release of the Swiss Post integration — tracking for parcels carried by Swiss Post, Switzerland's national postal operator.

No account and no API key are needed: you enter the tracking number yourself, just like on Swiss Post's own tracking page. Both the 18-digit domestic number (printed as 99.00 1234.5678 9012 34) and international UPU codes (RR123456789CH) work.

New features

• Per-parcel sensors with the canonical status, Swiss Post's own status code, the expected delivery date, the weight and dimensions, and a link to the tracking page.
• Summary sensors — incoming parcels, next delivery and recently delivered — each carrying the full parcel list as an attribute so one dashboard card can render everything.
• A deliveries calendar — a read-only view of every parcel with an expected delivery, at no extra request.
• Events and device triggers for parcel registered, status changed, delivered and delivery-time changed, so your automations need no polling of their own.
• swiss_post.track_parcel / swiss_post.untrack_parcel services, so a dashboard button or an e-mail automation can add a parcel without opening the integration options.
• Tracking numbers are checked as you add them — a typo is caught right away, while a number Swiss Post does not know yet is accepted, because that is simply a parcel nobody has scanned so far.
• Opt-in status history — the full event timeline per parcel, in the language Swiss Post writes it.
• A manual refresh button and a diagnostic sensor showing when Swiss Post was last polled successfully.
• A configurable polling interval (15 minutes to 4 hours; default 30).

Known limitation — and how you can help

The whole request flow is verified against the live tracking API, but only one real parcel — delivered, domestic, to a home address — has ever been seen through it. That is why this ships as 0.9.0 rather than 1.0.0, and it is the one thing you can help with. Each of these writes a single line to your log with a ready-made issue link:

• A parcel waiting at a post office is the biggest gap. Swiss Post plainly has the concept, but the status value it reports for it has never been observed, so such a parcel shows as unknown rather than at_pickup_point. The integration still recognises the situation from the post-office fields and flags the parcel for pickup — reporting the logged line is all it takes to finish the mapping.
• Only one status value is confirmed. The rest of the vocabulary is mapped from a third-party client and has not been seen in live data. An unrecognised value reports unknown rather than guessing.
• A parcel with a real delivery time window has never been seen; Swiss Post has so far only ever given a delivery date. The first one that carries a window asks you to confirm the expected delivery reads correctly.
• Parcel dimensions are three unnamed numbers. They are shown as length × width × height, which is the obvious reading but not a confirmed one. If you know a parcel's real size, the log line asks you to check it.

These reports say nothing about you or your parcel: the integration logs field names, never their contents.

Other limitations

• Pickup locations show a postcode rather than a name. When a parcel routes to a post office, Swiss Post gives the office's postcode and nothing else on this endpoint.
• Parcels from abroad appear late. Cross-border parcels are customs-cleared and often carried by a foreign operator first, so Swiss Post only sees them once they enter its own network. Such a parcel can sit at unknown for a while and then appear mid-journey — that is Swiss Post's view of it, not a fault in the integration.
• Only parcels you enter yourself. Swiss Post's tracking API has no signed-in inbox to read, so there is no parcel feed to subscribe to.

---

📦 See every supported carrier — new ones land regularly.