Primitive Types

The API uses all of the standard JSON data types, with a few distinctions and additions.

Type	Description	Example
`string`	A standard JSON string.	`"Test String"`
`integer`	A JSON number where the fractional part is ignored and should not be included.	`42`
`float`	A JSON number where the fractional part is possibly significant and should be included.	`3.14`
`boolean`	JSON literal `false` or `true`.	`true`
`date`	A JSON string using ISO 8601 date formatting (see below).	`"2016-06-02"`
`datetime`	A JSON string using ISO 8601 date formatting.	`"2016-06-02T17:14:01Z"`
`reference`	A JSON string that contains a root-relative URL (see below).	`"/v1/contacts/1000"`
`colour`	A JSON string that contains a RGB colour that has been hex encoded (see below).	`"#a1b2c3ff"`

📘
Null, Blank Strings, and Empty Collections
The API will avoid serializing null, "", [], or {} values in order to have a more compact response. They will not be included in any responses, and should also be avoided in requests.
Documentation will refer to attributes which can have these values as "nullable" or "optional".

Dates and Timezones

JSON has no native type for dates and times, so the API will use ISO8601 formatted string for all dates and times. Attributes using the date type will only include the calendar date portion of the time string. Attributes using the datetime type will ignore sub-second precision.

🚧
All datetime strings should be specified in UTC to avoid timezone issues.
Example: "2016-01-02T13:15:30Z"

References

Every Daylite object has a URL that is unique within its data set. In general the API follows the pattern of /:version/:object_type for list of all Daylite objects of a certain type. Individual objects URLs follow the pattern /:version/:object-type/:object-id.

Colours

Colours are presented in hex encoding, using the RGB colour space. They may include a fourth octet for the colour opacity.

Major Objects

Major objects are top-level objects in the API which can stand alone without being part of another object. Each major object has its own documentation section:

Minor Objects

Minor objects are objects which normally only exist within a major object. Each minor object has its own documentation section:

Social Profiles, E-mail, URLs, Phone Numbers, and Addresses

Some minor objects can be enumerated via API endpoints:

Linking

Linking is one of the superpowers of Daylite. Linking allows users to specify relationships between Daylite objects. The Daylite API allows you to retrieve, create, and delete links between objects.

Most links express more than just a relationship between objects and have properties that describe the relationship of objects to each other. See the documentation on Roles for more details.

📘
Link URLs
Links are not part of Daylite objects, they exist as a glue between objects. The Daylite API represents most links as a collection within the object. Some link types, such as emails, follow the pattern of
/v1/:object-type/:object-id/:linked-object-type
For example, the list of links to a company for a specific contact has a URL like:
/v1/contacts/1000/emails

Ownership

Every major object has a creator and an owner attribute, which are User references.

The owner attribute is used to assign responsibility of an object to a user. In general this means that the owner has administrative permissions for the object, but for some major objects the owner will also receive notifications when the object is changed by another user.

The owner can be set when an object is created, and it can also be changed later by object updates. If an owner is not set during object creation, the value will default to the same value as the creator.

Unlike the owner, a major object's creator is always set automatically to the user that created the object. This cannot be overridden, and it cannot be changed later, it is meant more for record keeping.