How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Laurel Entry Date Restrictions API

The Entry Date Restrictions API from Laurel — 5 operation(s) for entry date restrictions.

Laurel Entry Date Restrictions API is one of 40 APIs that Laurel publishes on the APIs.io network, described by a machine-readable OpenAPI specification.

Tagged areas include Entry Date Restrictions. The published artifact set on APIs.io includes an OpenAPI specification, API documentation, and authentication docs.

This API exposes 8 operations across 5 paths, and defines 11 schemas. It is described by OpenAPI 3.0.0, at version 1.

Requests are made against the base URL https://api.laurel.ai/time/.

8 operations 5 paths 11 schemas 1 DELETE3 GET1 PATCH3 POST

Metadata

The identity and technical contract details declared by the specification.

Specification
OpenAPI 3.0.0
API Version
1
Base URL
https://api.laurel.ai/time/
Authentication
HTTP Bearer
Resource Areas
1

Authentication & Security 1

Laurel Entry Date Restrictions API declares 1 security scheme for authenticating requests. It accepts HTTP bearer tokens (JWT) (ApiBearerAuth). By default, every request must be authenticated.

  • ApiBearerAuth — Enter access token

Paths & Operations 8

Across 5 paths, the API surfaces 8 operations — 1 DELETE, 3 GET, 1 PATCH, 3 POST. Each is listed below with its method, path, parameters, and response codes.

Entry Date Restrictions 8
POST
/api/v1/customers/{customerId}/entry-date-restrictions
Create a new entry date restriction for a customer
CustomerEntryDateRestrictionController_create_v1 1 param body → 201
GET
/api/v1/customers/{customerId}/entry-date-restrictions
List entry date restrictions for a customer
CustomerEntryDateRestrictionController_list_v1 7 params → 200
GET
/api/v1/customers/{customerId}/entry-date-restrictions/active/nowdeprecated
DEPRECATED — use active/check-multi-type instead. Check if an active restriction exists for a given work date and type.
CustomerEntryDateRestrictionController_checkActive_v1 5 params → 200
POST
/api/v1/customers/{customerId}/entry-date-restrictions/active/checkdeprecated
DEPRECATED — use active/check-multi-type instead (pass a one-element types array). Check which of the provided work dates have an active restriction for the given type.
CustomerEntryDateRestrictionController_checkActiveBatch_v1 1 param body → 200
POST
/api/v1/customers/{customerId}/entry-date-restrictions/active/check-multi-type
Check which of the provided work dates have active restrictions across multiple types
CustomerEntryDateRestrictionController_checkActiveMultiType_v1 1 param body → 200
GET
/api/v1/customers/{customerId}/entry-date-restrictions/{id}
Get a single entry date restriction by id
CustomerEntryDateRestrictionController_getOne_v1 2 params → 200
PATCH
/api/v1/customers/{customerId}/entry-date-restrictions/{id}
Update an entry date restriction
CustomerEntryDateRestrictionController_update_v1 2 params body → 200
DELETE
/api/v1/customers/{customerId}/entry-date-restrictions/{id}
Delete an entry date restriction
CustomerEntryDateRestrictionController_softDelete_v1 2 params → 200

Schemas 11

The contract defines 11 schemas that model the data the API accepts and returns. The most detailed are EntryDateRestrictionResponseDto (12 properties), InitiativeDigest (7 properties), CreateEntryDateRestrictionRequestDto (6 properties), CheckActiveRestrictionsMultiTypeRequestDto (6 properties). Each schema is shown below with its type and property counts.

ExactDatesRuleDto
object
2 properties 2 required
InitiativeDigest
object
7 properties 4 required
TypeRestrictedDatesDto
object
2 properties 2 required
CheckActiveRestrictionsBatchRequestDto
object
5 properties 2 required
RestrictedDateDto
object
2 properties 2 required
CreateEntryDateRestrictionRequestDto
object
6 properties 6 required
EntryDateRestrictionResponseDto
object
12 properties 10 required
CheckActiveRestrictionsMultiTypeResponseDto
object
1 property 1 required
UpdateEntryDateRestrictionRequestDto
object
5 properties
CheckActiveRestrictionsBatchResponseDto
object
1 property 1 required
CheckActiveRestrictionsMultiTypeRequestDto
object
6 properties 2 required

Specification

The full machine-readable OpenAPI contract behind this narrative.

Source

laurel-entry-date-restrictions-api-openapi.yml Raw ↑

Other APIs Laurel publishes across the network.

Laurel Ably API
Laurel Activities API
Laurel Clients API
Laurel Code Types API
Laurel Codes API
Laurel CodeTypes API
Laurel Customers API
Laurel DailySelectedInitiatives API
Laurel Data Retention Audits API
Laurel Delegators API
Laurel Entries API
Laurel Exports API
Where this information came from

This is an independent, third-party profile of Laurel Entry Date Restrictions API, published by API Evangelist. We do not operate, host, resell, or support these APIs, and we are not affiliated with or endorsed by the company unless stated above. Everything here is built from publicly available information — the company's own site, developer portal, documentation, public repositories, and the specifications it publishes for public use. Nothing is obtained by breaching a system, defeating an access control, or using credentials.

The Kin Score and Agent Readiness rating are independently calculated assessments of a company's public API artifacts, scored against a published rubric. They are not certifications, endorsements, security assessments, or audits.

Corrections, re-scores, and removal are free — no partnership or purchase required, and you do not need to justify the request. A removed company is recorded as unrated, never scored zero for having asked. Acknowledgement within one business day; removal within two.

info@apievangelist.com · Read the full data-sourcing policy →
On a security or compliance team? Put security in the subject line and you will get a person, not a form — we will tell you exactly which public URLs this profile was built from.