PublicAPI Requests and Responses
Note
It is advised that the user of this guide has a fundamental understanding of the PublicAPI functions.
The section provides the information necessary to allow users to access the Full Suite of Public API requests and Responses. These Requests and Responses are available to view in Swagger.
Swagger provides an intuitive interface for users who require access to the complete range of available PublicAPI Requests and responses.
Swagger can be accessed at the following URL: https://<url>/AMAG.Public/api/swagger-ui/index.html
Note
Replace the <url> placeholder with the customer-specific URL.
This tool allows the user to explore, test, and understand the various API endpoints and their respective functionalities.
Example Validations
The following sections are useful examples of the types of internal validations that are completed in the background and are not available externally in the information provided by Swagger.
Note
The following examples were requested by a user/customer and is specific to their use case. If required, please contact AMAG Technical Support for further details regarding internal validations.
PUT http://connect.<url>.com/visitors/{VisitorId}
Besides already posted in Swagger requirements, the following validations are performed:
Visitor First Name
Visitor Last Name
Visitor Company
If email notifications are turned on - an email address is required
If SMS notifications are turned on - mobile phone number is required
Primary email is required
Email format is validated
Visitor cannot be the same as the identity of type Employee
Validation against configured fields and UDFs
POST http://connect.<url>.com/visits/accessgroupsbynameiffound
Besides already posted in Swagger requirements, the following validations are performed:
Host Identity must exist
Host Identity must have a Host Role (Host, Host Delegate, Receptionist)
Must provide valid Visitor IDs
Host Employee Number must exist
Must have a valid Building Identifier
Must have a valid Visit Type
Only UserDefinedFields OR UserDefinedFieldsByName can be passed in (not both)
Length MAX validation
Floor (max 50 characters)
Location (max 100 characters)
Title (max 50 characters)
Citizenship (max 50 characters)
VehicleMake (max 50 characters)
VehiclePlateNumber (max 20 characters)
VisitJustification (max 500 characters)
Arrival DateTime Local ahead of Departure DateTime Local
If not all-day, arrival must be 20 minutes before midnight (UTC)
If all-day, validate for Arrival/Departure
Validate configured Max Visit in Advance and Max Visit Days
If Host Delegate - validate if allowed
If Host, validate if allowed based on role
Must be a valid Host
Validate if Visit Approval is required
If ImmediateSyncToPACS
CardNumber is not allowed
Validate Explicit Access
POST http://connect.<url>.com/visitors
Besides already posted in Swagger requirements, the following validations are performed:
If email notifications are turned on - email address is required
If SMS notifications are turned on - mobile phone number is required
Email format is validated
Last Name
First Name
Validation against configured fields and UDFs
Validate Host Company
Validate Building
POST http://connect.<url>.com/visits/{VisitId}/grant_access_groups
Besides already posted in Swagger requirements, the following validations are performed:
Required ExplicitAccessGroups
Valid Building
If ImmediateSyncToPACS
Validate Explicit Access
Validate if Visit Approval is activated, and check the current status
Validate Access rules
Validate explicit access that will sync at check-in
Validate: Is Employee and Explicit Options Configured on Rule, and Does Not Apply to Employee/NonEmployee
Validate: if true - active ExplicitAccess Options rule
Previous access exists, and the new vs old do not match on syncAtCheckIn status
validate against the excluded access groups defined
Validate against access codes already defined on access rules
Validate if pre-check-in is active and the defined access codes match the proposed
Validate if the request's ExplicitVisitAccessData.AccessGroupData matches the existing visit's ExplicitVisitAccessData.AccessGroupData
Validate explicit access scheduled:
validate integration
Validate that the new activation date is greater than the expiration dates (UTC)
Expiration date (UTC) is greater than Visit's departure date (UTC)
Activation Date (UTC) is less than the visit's arrival date (UTC)
Validate new schedule
New access group activation date is greater than the current UTC
If the visit has started, the expiration date (UTC) must be greater than 30 minutes at the current UTC, or the expiration date (UTC) must be greater than 30 minutes past the visit's arrival date (UTC)