Dialogporten Reference Entities Attachment

Attachment

Reference information about the attachment entity

Select environment: Help

This dropdown lets you select which Dialogporten environment the content of this page should be based on. If unsure, use the default "Staging (TT02)", as this is the environment you would normally test against when integrating Dialogporten.

For bleeding edge, select "Dev", as this contains the most recent unreleased changes to the Dialogporten API. Select "Local dev" if you want to test changes to Dialogporten itself running locally.

Attachments represent logical files plus one or more concrete URL representations of those files.

An attachment consists of:

metadata such as displayName and optional logical name
one or more URLs in urls
optional expiresAt

Each URL represents one concrete attachment representation and can vary by:

mediaType
consumerType

This allows the same logical attachment to be exposed in different formats for different consumers, for example a PDF for GUI frontends and JSON or XML for API consumers.

Attachments can exist at two levels:

on the dialog root
on individual transmissions

Dialog-level attachments follow dialog-level authorization by default, but can carry their own authorization context to narrow access further - access to the dialog remains a precondition.

Transmission attachments follow transmission-level authorization by default, with the same option to carry their own authorization context - access to the transmission remains a precondition. In end-user APIs, an attachment’s URLs are rewritten to urn:dialogporten:unauthorized when the user is not authorized to access it - or, if its unauthorizedPresentation is Excluded, the attachment is removed from attachments and only its id and creation time appear in excludedAttachments beside it. When the attachment carries an authorization context the current user is authorized for, the dialog token lists the attachment’s id (or the context’s tokenRef) in its e claim.

Read more