Webhooks
Time-to-live
If the consumer is down, events will be stored for one day (86400 seconds).
Error handling
Depending on the HTTP response codes from the consumer the following actions will be taken
State | Action | Comment |
---|---|---|
<connection problems> | Retry | With exponential back-off (powers of 2) |
HTTP code [200,299] | Success | Â |
HTTP codes [300,399] + 410 | Abort web hook | Â |
HTTP codes [400,599] - 410 | Retry | With exponential back-off (powers of 2) |
Unknown HTTP code | Retry | With exponential back-off (powers of 2) |
Formats
The following two formats are supported
Format | Description | Since |
---|---|---|
Xml | Outputs in XML using a Premis event V2 | Â |
XmlPremisV3 | Outputs in XML using a Premis event V3 https://www.loc.gov/standards/premis/v3/index.htmland includes the Difference. |
|
Example for XmlPremisV3
Example format Xml (default)
Event Types
The different event types are documented here Events
Web hooks always contain the fully qualified event type such as
RECORDS.FLOW.ARCHIVED
Premis Links
The links in a premis event have of the two following formats
MediaObjectId
(64 characters)FragmentId
(96 characters)
Variants
When the link is a
MediaObjectId
the event pertains to all fragments of the recordWhen the link a
FragmentId
the event pertains to only this specific fragmentsCertain events such deleting the entire record will emit a
DELETE
event for each fragment with its ownFragmentId
Tip
When requesting the events in JSON format you are guaranteed to always have the property FragmentId
in addition to the Links
whereas in the XML format only the links viapremis_event:linkingObjectIdentifier
are present
Permissions change
When the permissions of a record change in such manner the web hook user gains or losses the read right, in a narrow period around this transition events could be missed.
As such the UPDATE event which removes or adds the read right of the web hook user, may or may be not received by the web hook user.