Message Lifecycle

The message lifecycle describes how a digital message moves through the Digital Post Platform from initial submission to final deletion.

Understanding this lifecycle is essential for implementing reliable integrations, monitoring delivery, and handling errors.

Each message progresses through a defined sequence of stages.

From the integrator perspective, the lifecycle begins when an envelope is submitted and ends when the message is no longer available to recipients.

High level lifecycle stages:

1. Preparation
2. Submission
3. Validation
4. Processing
5. Delivery
6. Access
7. Retention
8. Deletion

Not all messages reach every stage.

Messages may terminate early if validation or processing fails.

In the preparation stage, the integrating system creates all required artifacts.

This includes:

• Message body files
• Attachment files
• Envelope documents
• Encryption material, if applicable
• Delivery metadata

No interaction with the platform occurs during this stage.

All preparation is performed by the integrator.

Submission occurs when a delivery is created using the Delivery API.

During submission:

• Storage connection details are provided
• Optional encryption keys are supplied
• The platform is instructed to begin processing

After submission, content must remain available in storage until processing completes.

Removing content prematurely may cause failures.

After submission, the platform performs structural and semantic validation.

Validation includes:

• Envelope schema validation
• Required field verification
• Sender permission checks
• Recipient format validation
• File reference verification
• Message identifier validation

If validation fails, the message is rejected.

Rejected messages do not proceed further in the lifecycle.

During processing, validated messages are prepared for delivery.

Processing includes:

• File retrieval
• Virus scanning
• Optional decryption
• Content normalization
• Recipient resolution
• Subscription verification
• Message rendering
• Metadata indexing

Processing may occur asynchronously.

Large deliveries may take extended time to complete.

Once processing succeeds, the message enters the delivery stage.

During delivery:

• Encrypted content is assigned to recipient mailboxes
• Access permissions are applied
• Notifications may be scheduled
• Message metadata becomes visible

Delivery is atomic per envelope.

All recipients receive the message simultaneously.

After delivery, recipients can access the message.

Access includes:

• Viewing metadata
• Opening message body
• Downloading attachments
• Triggering receipts
• Performing allowed interactions

Access behavior depends on message configuration and sender permissions.

If open receipt is required, access may be restricted until receipt registration.

Delivered messages are retained according to platform and regulatory policies.

Retention parameters may include:

• Minimum storage duration
• Legal hold requirements
• Archival rules
• Market specific regulations

Retention policies are defined by the platform holder.

Integrators do not control retention directly.

After the retention period expires, messages may be deleted.

Deletion includes:

• Removal from recipient mailboxes
• Removal from active storage
• Archival cleanup
• Metadata anonymization, if applicable

Deleted messages cannot be recovered.

Deletion timing is controlled by platform policies.

Not all messages complete the full lifecycle.

Several exceptional paths exist.

If validation fails:

• The message is rejected
• A failure entry is recorded
• Processing stops
• No delivery occurs

The message remains only in integrator storage.

If processing fails:

• The envelope is marked as failed
• Diagnostic information is recorded
• Other envelopes may continue

Failures may occur due to:

• Virus detection
• Missing files
• Decryption errors
• Recipient resolution failure

If interim delivery is enabled and a recipient has no active account:

1. Message enters interim storage
2. Recipient is notified
3. Message is held temporarily
4. Delivery resumes after account creation

If no account is created within the retention period, the message is removed.

If delayed delivery is configured:

1. Message is processed
2. Message is stored securely
3. Delivery is postponed
4. Message becomes available at the scheduled time

During postponement, messages remain inaccessible to recipients.

Integrators can observe lifecycle progression through:

• Delivery status
• Envelope logs
• Delivery reports
• API responses

Only high level states are externally visible.

Internal processing stages are abstracted.

Delivery status reflects lifecycle stages.

Envelope level logs provide more detailed information.

Each message is identified by a unique messageId.

Once delivered:

• The same identifier cannot be reused
• Duplicate submissions are rejected
• Historical records are preserved

Message identifiers form part of the lifecycle traceability.

Throughout the lifecycle, the platform records:

• Submission timestamps
• Processing events
• Delivery outcomes
• Access events
• Error conditions

These records support:

• Regulatory compliance
• Incident analysis
• Usage reporting
• Billing processes

Audit data access depends on permissions.

Recommended integration practices include:

• Validate envelopes before submission
• Monitor delivery reports
• Implement retry logic
• Handle interim scenarios
• Respect retention policies
• Avoid identifier reuse
• Maintain processing logs

Following these practices improves reliability and supportability.

The message lifecycle builds on:

• Organisational Model
• Message Delivery Model
• Authentication Setup
• Delivery API Reference

Understanding these sections together provides a complete operational view.

For more information, see:

• Message Delivery Model
• Security Concepts
• Delivery API
• Error Handling Guide