Deutsche Post
Purpose
This connection buys stamps, not parcel labels. It exists for letter mail — invoices, reminders, small goods shipments — and therefore behaves fundamentally differently from any parcel connection.
Scope
- Purchase of an internet stamp from inside the shipping process.
- Maximum weight 1,000 g per item.
- The stamp id is kept as a number. It identifies the purchase, not the path of the item — but it
is the only handle this item will ever have, and without it nobody could tell which stamp belongs to which transaction.
Setup
Credentials live as an integration under Integrations — provider deutschepost. The credential names start with the provider, which keeps them apart from the settings of other connections.
| Setting | Required | Meaning |
|---|---|---|
deutschepost_api_key | yes | Application key of the internet stamp. Stored encrypted and never shown again. |
deutschepost_portokasse_user | yes | Portokasse user — the credit account every stamp is charged to. Stored encrypted and never shown again. |
deutschepost_portokasse_password | yes | Its password. Stored encrypted and never shown again. |
default_product_id | yes | Product number of the stamp when the shipment names none (an item of the Deutsche Post price list). |
sender | no | Sender address as a group of fields; passed to the internet stamp unchanged, field names as in its interface. |
production | no | true switches to live operation. Without it everything runs against the test environment. |
Credentials still stored in clear text under the old name without the provider prefix are taken over encrypted — on the next save or read of the integration and by the update step "Store credentials encrypted" (bin/console app:secrets:migrate).
In live operation every stamp produced costs real money from the Portokasse, and the interface does not take it back.
Interplay
The connection sits inside Shipping: that is where the shipment is created, where the label is bought and where tracking runs. Credentials live as an integration under Integrations in the encrypted store — never in a setting and never in clear text; the same place switches between test environment and production. Labels and delivery notes reach the right printer through Printing & workstations. When a label is produced, and in how many copies, is decided by automations — shipping brings no rule engine of its own.
Limits
- No tracking. A letter is not tracked. Claiming otherwise would make the nightly reconciliation
wait for information that does not exist.
- No cancellation. The stamp is paid at purchase; the interface does not take it back.
- No return label — returns in letter mail use a different product.
- No fixed product list. Product ids are positions in a price list that Deutsche Post changes
without us and that differs per contract. Which product applies is decided by the shipping rule or by configuration — a list in code would be a number nobody maintains.
- Customs documents for third-country letter mail are produced on paper (CN22/CN23), not through
this interface.
- The real run is still outstanding. What is verified is that we ask correctly and read the
answer correctly — the tests drive the interface with prepared responses. That Deutsche Post actually accepts the request we build is not proven; access to the real test environment is missing.
- Prices and contract terms do not come from here. What a shipment costs is in the contract with
the carrier; this connection buys the label, it does not price it.