Xink Developer API

We use OAuth2 to control access to Xink APIs; external clients should use ClientCredentialsGrant in particular. The client should request the access token from the Xink authorization server, then use the token in all subsequent requests to the Xink API.

Xink API URL for fetching the first three employees would be api/1.0/employee/list/0/3

The response contains Offset and Limit parameter values used in the request (or defaults if not parameters are supplied). In the array of Items, each represents one employee.

Employee list items:

• Email — employee email is a system-wide unique value used to refer employee in any calls. Cannot be empty.
• FirstName — corresponds to Xink First name field.
• LastName — corresponds to Xink Last name field.
• DisplayName — corresponds to the Xink Display Name field. Cannot be empty.

URL for fetching John Doe’s signature would be api/1.0/employee/johndoe@example.com/signatures

The response contains the Clean flag which represents the value of “Delete all existing email signatures in Outlook” preference; SetDefault and SetReply flags indicating if the client application is supposed to assign new/reply signatures in Outlook and actual array of Signatures and Images.

Signature list items:

• Name — the name of the signature in Xink, the same value is displayed in the web application, in the signature list. Cannot be empty.
• HTML — this is the actual HTML signature with all substitutions performed, ready for use by a specific employee.
• Text — plain text version of the signature, also ready for use.
• DefaultNew — a boolean flag indicating that the signature is configured to be the default for new messages.
• DefaultReply — a boolean flag indicating that the signature is configured to be the default for forward/reply messages.

Images list items:

• Name — file name for the image
• URL — direct link to fetch the image.

The signature is supposed to be downloaded directly into the “Signatures” folder of the Outlook user profile. Each signature must be saved into a file named exactly as field Name value with the .htm extension added.

URL for fetching John Doe’s fields would be api/1.0/employee/johndoe@example.com/fields

The response contains an array of Fields.

Field list items:

• Code — internal name of Xink field; used by Xink to refer field data in signatures, like ((Mobile)). Mobile is the code.
• DisplayName — human-readable name (or description) of the field.
• FieldValue — the actual value of the field for the corresponding user in a moment when API calls made.

Upload list items:

• Email — employee email. A mandatory field, a unique employee identifier in the system-wide.
• FirstName — corresponds to Xink First name field. A mandatory field for new employees. It can be left blank for already existed employees. It won’t change in this case.
• LastName — corresponds to Xink Last name field. A mandatory field for new employees. It can be left blank for already existed employees. It won’t change in this case.
• DisplayName — corresponds to the Xink Display Name field. Can be empty. In this case “FirstName LastName” will be applied.
• Fields — a list of the employee custom fields. Only the fields in the list are gonna change. The field FieldValue can be empty. The fields should be created in Xink. If the request contains the fields, which can’t be found in Xink, the employee won’t be added. The server answer contains the message with the successful employee update or error description.

Delete list items:

• Email — employee email. A mandatory field, a unique employee identifier in the system-wide.

The signature may contain images, like the company logo, employee avatar or whatever else. Xink stores those images and performs several actions to prepare Outlook application to use them properly.

Field Name provides the exact file name for the corresponding image. Images supposed to be saved in the same directory as signatures. It is important; signature HTML refers to images just by file name.

Xink server is responsible for making image names unique. If in any case image names are repeated, it is guaranteed that these are references to the same image.

There is no dedicated authorization scope for image access. It is enough to provide a token generated for a valid client account.

Example

            var body = client.GetStringAsync(
                new Uri(
                    resourceServerUri,
                    "/api/1.0/employee/johndoe@example.tld/signatures"
                    )
                ).Result;