Skip to end of banner
Go to start of banner

Manual webhook CMS

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 7 Next »

1. Types of state

A request has status attributes that allow monitoring the progress of the process in the application.

  • CREATED: the request has been created and associated with an RA, but the content of the request has not yet been validated. In the state, the data may also be inconsistent; the system will not throw an error. The content of the request can be edited at any time to make it valid.

  • ENROLLREADY: The certificates are ready to be issued. The request reaches this stage if it has been approved and signed by an RAO, who is part of the RA in charge of the request.

  • ISSUED: The certificate is issued through the user’s self-service page on the platform. First, the user must set a PIN code or password for the secure element.

Certificate States:

  1. ACTIVE

  2. SUSPENDED

  3. REVOKED

  • RENOVATED: The certificate is renewed through the user’s self-service page on the platform.

  • CANCELED: The request is canceled, and the digital certificate cannot be issued.

For more information about the states, you can visit the following page.

https://ra-uanataca-docs.redoc.ly/#section/Glossary

2. Webhook notifications

2.1. Flow States of a Paperless Request

  1. Request created

{"event_type": "REQUEST_CREATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "CREATED", ...}, "certificates": []}

a. Request canceled

{"event_type": "REQUEST_CANCELED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "CANCELLED", ...}, "certificates": []}

b. Request approved

{"event_type": "REQUEST_APPROVED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ENROLLREADY", ...}, "certificates": []}

c. Request in Issued State (Certificate Issued)

{"event_type": "REQUEST_ENROLLED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "VALID", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

d. Certificate suspended

{"event_type": "CERTIFICATE_SUSPENDED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "SUSPENDED", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

e. Certificate reactivated

{"event_type": "CERTIFICATE_ACTIVATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "VALID", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

f. Certificate revoked

{"event_type": "CERTIFICATE_REVOKED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "REVOKED", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

2.2. Flow states of a VideoID Request

  1. Request Created

{"event_type": "REQUEST_CREATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOPENDING", ...}, "certificates": []}

a. Request canceled

{"event_type": "REQUEST_CANCELED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "CANCELLED", ...}, "certificates": []}

  1. VideoID completed by the User

2.1. The data has been approved by the service and is being processed

{"event_type": "VIDEOID_UPDATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOINCOMPLETE", ...}, "certificates": []}

2.2.Request rejected due to a documentation-related issue

{"event_type": "VIDEOID_FAILED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOERROR", ...}, "certificates": []}

  1. Data ready for review

{"event_type": "VIDEOID_UPDATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOREVIEW", ...}, "certificates": []}

  1. Approval or rejection by RAO

4.1. Approval

{"event_type": "REQUEST_APPROVED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ENROLLREADY", ...}, "certificates": []}

4.2. Rejection

{"event_type": "VIDEOID_REFUSED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "CANCELLED", ...}, "certificates": []

  1. Request in issued state (Certificate issued)

{"event_type": "REQUEST_ENROLLED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "VALID", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

3.Event Structure

Here the key focus is on the “status” attribute, as it is a present in both the request object and the certificates object. It is essential to understand that these “status” attributes are not comparable to each other, as they represent different entities:

The request.status key is the primary one within this context because it represents the state of the issuance process. This “status” is directly related to the request’s flow and reflects its progress or completion.

request.status: indicates the status of the request.

certificates[].status: indicates the status of the certificate.

Althought both share the same key name, each belongs to a different context and carries a specific meaning.

  • No labels