Skip to content

Berichtenbox delivery waits on the Logius connection and answers to Q1 to Q9 #2605

Open

Description

@rubenvdlinde

What is missing

No Berichtenbox letter reaches a real citizen yet. The client follows the Logius interface, but every live proof ran against an XSD-validating fake.

Why it matters

dossiq and pipelinq send digital post through integriq. Until the connection is live, those letters stop at integriq.

Where

  • Client: lib/Service/DigitalPost/ (BerichtenboxClientHttp, ebMS adapter, WUS ValidateAbonnementen).
  • Open questions: openspec/changes/berichtenbox-client/design.md, section "Questions only Logius can answer".

Already done

What is needed

  1. A Logius connection (aansluiting) for the customer organisation: OIN, PKIoverheid certificate, access to the test environment, and a CPA.
  2. Answers from Logius to the nine questions in design.md:
    • Q1. Which ebMS profile and Digikoppeling version does the Berichtenbox CPA demand today?
    • Q2. The CPA values for a sender: service, party ids, roles, endpoints, retry schedule, synchronous or asynchronous acknowledgement.
    • Q3. Which wins: S1 says Omschrijving is at most 40 characters, the XSD allows 128. Should the request import the _128ch types file?
    • Q4. May a sender call WUS ValidateAbonnementen once per letter, and at what volume does Logius want the ebMS AbonnementService instead?
    • Q5. How long can a GLOBE-R-BV-Result take?
    • Q6. What does EindDatumHandelingsTermijn trigger? It is in the XSD, not in S1.
    • Q7. Does a new connection on GLOBE have to move to BBO later, and with how much notice?
    • Q8. What does a connection cost, for an organisation and for an intermediary?
    • Q9. Does BerichtBestaatAl on a resend mean the first letter reached the citizen?

Done when

  • The answers are recorded in design.md and the code follows them (for example the Omschrijving limit, the CPA values).
  • One letter is sent and its result received on the Logius test environment, with the evidence in the PR.

Related: #859 (older Berichtenbox adapter change).

Activity

  1. github-actions commented on Oct 8, 2026

    @github-actions
    Contributor

    Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

    What happens next:

    1. A maintainer will review this issue and determine the appropriate action
    2. If accepted, it may be converted into an OpenSpec change for structured development
    3. You will be notified of any status changes

    Triage labels:

    • triage:accept-feature — accepted as a new feature
    • triage:accept-bugfix — accepted as a bug fix
    • triage:needs-info — more information needed
    • triage:wontfix — will not be addressed
    • triage:duplicate — duplicate of another issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requesttriageAwaiting triage

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions