Send Applicaiton Receipt
For detailed technical specifications, please refer to the Swagger documentation.
Upload Application Receipt as an XML Document
The application receipt may be uploaded like any other business document, see the sending messages endpoint page. The same process and validation rules apply. Please note that an application receipt always has exactly one receiver.
Send with the AppRec API Endpoint
POST /messages/{id}/apprec
We offer a separate endpoint for producing and sending application receipt. If called, EDI 2.0 will create an application receipt XML document based on the information provided. The created XML is then sent to the recipient in the normal way.
Request
| Property | Type | Required | Description |
|---|---|---|---|
appRecSenderHerId |
integer |
✅ | HER‑ID of the AppRec business document sender. By default used as the envelope sender of the AppRec. Must be a business document receiver of the original message. |
appRecStatus |
enum AppRecStatus |
✅ | Application receipt status. |
appRecErrorList (optional) |
AppRecError[] |
— | List of error objects required when appRecStatus = Rejected. |
applicationName |
string | ✅ | Name of the calling application/EPJ. |
applicationVersion |
string | ✅ | Version of the calling application/EPJ. |
transportMetadataOverrides (optional) |
AppRecTransportMetadataOverrides |
— | Allows overriding some automatically derived EbXml fields. Use only when you have a non‑standard exchange requirement. |
appRecStatus and appRecErrorList should be provided based on the domain logic of your application/EPJ. If your application rejects the message, you should provide the reason(s) for this.
Response
| Property | Type | Description |
|---|---|---|
| id | string |
Reference ID for the shipment of the application receipt. |
A recipient using EDI 2.0 can provide id to retrieve their application receipt.
You, the sender, can view the status of the application receipt by providing id. Read more on the status endpoint page.
Key Considerations for Using the AppRec API Endpoint
For requests to succeed, EDI 2.0 has to already have read, parsed and stored the communication parties in the referenced message. We cannot guarantee that this is the case for all messages. They must at the very least be XML messages that are well formed, and following a schema we know about.
Trying to produce application receipts for messages not following the standard for addressation (tjenestebasert adressering - HIS 1153:2017), may lead to unexpected results and possible mismatch between the addressees of the business document and the shipment/EbXml envelope. The same can be true if there already was a mismatch between the business document addressees and shipment/EbXml envelope in the referenced message.
To create the application receipt XML, the "sender" and "receiver" XML-elements from the original message is swapped (in case of copy receivers, the "receiver" or "otherReceiver" element corresponding to the provided HER-Id is swapped with the "sender" element). In the shipment and EbXml envelope of the application receipt, the provided AppRecSenderHerId is used as the sender (EbXml "From"), while the receiver (EbXml "To") is the sender (EbXml "From") of the shipment and EbXml envelope of the referenced message.
Send AppRec with Custom Metadata for the (EbXml) Envelope
See the sending messages endpoint page for the general details and use-case for the transportMetadataOverrides-properties.
In the AppRec request model, there are two additional properties:
TransportReceiverHerIdoverrides the receiver of the application receipt shipment and/or EbXml envelope.TransportSenderHerIdoverrides the sender of the application receipt shipment and or EbXml envelope.
These properties should only be used in exceptional cases, when communicating with parties that don't follow the standard HIS 1153:2017 or other cases that requires special treatment. For instance, NAV requires communication on level 1 in AR, and is the main situation where you should use overrides.