Skip to content


An access the way Entryfy handles giving users permissions to resource whether it be a physical door or a network relay. In an access you can define which users have access to which doors during what times. You can also customize which authentication types users can be allowed when either entering or exiting through the door, gate, locker or storage unit.

Create an access#

First step is creating a CreateAccessesRequest message which contains AccessBodies and organization_slug.

The organization_slug is an identifier for the organization you which to work with. This is given to you with your first credentials when getting an account at Entryfy.

message CreateAccessesRequest {
    string organization_slug = 1;
    repeated AccessBody access_bodies = 2;

AccessBody is the definition of the access and consists of a uuid, name, kind, schedule and a set of doors and users. If you choose to define a temporary access you will also be required to supply a valid_to date. The difference between a permanent and a temporary access is that after an temporary access expires it will be removed from the hardware to save resources.

For more information see our knowledgebase article: Introduction to Entryfy Entities

message AccessBody {
    string uuid = 1;
    string name = 2;
    enum Kind {
        KIND_PERMANENT = 1;
        KIND_TEMPORARY = 2;
    Kind kind = 3;
    enum Status {
        STATUS_INITIAL = 1;
        STATUS_READY = 2;
        STATUS_CREATING = 3;
        STATUS_UPDATING = 4;
        STATUS_DELETING = 5;
        STATUS_DELETED = 6;
    Status status = 4;
    map<string, string> preferences = 5;
    google.protobuf.Timestamp valid_from = 6;
    google.protobuf.Timestamp valid_to = 7; // Mandatory for temporary accesses
    google.protobuf.Timestamp created_at = 8;
    google.protobuf.Timestamp updated_at = 9;
    Schedule schedule = 10;
    repeated AccessDoor doors = 11;
    repeated AccessUser users = 12;
    string description = 13;
    Boolean welcome_email_required = 14;

AccessDoor contains the uuid of the doors the users should have access to and what authentication types are required for each direction (in, out). You can also set lock_unlock_enabled if you want to keep an door or relay opened based on the schedule definition.

message AccessDoor {
    string uuid = 1;
    string access_uuid = 2;
    string door_uuid = 3;
    bool lock_unlock_enabled = 4;
    repeated string in_auth_types = 5;
    repeated string out_auth_types = 6;
    google.protobuf.Timestamp created_at = 7;
    google.protobuf.Timestamp updated_at = 8;

AccessUser contains the uuid of the user to include in the access. 

message AccessUser {
    string uuid = 1;
    string access_uuid = 2;
    string user_uuid = 3;
    google.protobuf.Timestamp created_at = 4;
    google.protobuf.Timestamp updated_at = 5;

The message is sent to the AccessesService to get back an authentication token that the client will use in subsequent requests and an reissue token that will be used to re-authentication as explained below.

    participant Client
    participant AccessesService
    Client->>AccessesService: CreateAccessesRequest
    AccessesService-->>Client: CreateAccessesResponse