dayrook
Book a walkthrough

API evaluation guide

Scope your Dayrook integration before writing against it.

Read the deployed OpenAPI schema, then check authentication, customer boundaries and failure behavior for the operations you need. Confirm endpoint permissions and environment support before connecting a workflow.

Open the API schema Plan an API integration

Versioned, scoped, and replay-safe

On this page2 sections

Public schema verified 11 October 2026 · endpoint access remains scoped

Choose the task you need.

Source: Deployed OpenAPI 3.1 schema and Dayrook route contracts

5 matching tasks

Route contracts

Every operation declares method, path, identity, tenant source, permission, region, rate, replay, schemas, audit action, and data access.

Authentication and scope

Use the operation's declared user session, service mTLS, agent mTLS, signed webhook, provider callback, signed URL, or health-probe contract.

Errors, retries, and idempotency

Preserve request identity, retry only typed retryable outcomes, and keep the same idempotency key for the same mutation intent.

Webhooks and replay

Verify the raw request, signature, timestamp, source, tenant mapping, event identity, region, and terminal recovery path before side effects.

Versions and contract changes

Breaking changes require an approved new API version or compatibility window. Confirm current route references and client-library availability before implementation.

First-time setup: review the evaluation sequence
Evaluation sequence

First request to safe production operation

  1. Open the public OpenAPI schema and identify the operation, method, path, declared authentication and request schema. Confirm the operation’s tenant, regional and permission requirements.
  2. Create only the authentication scheme and permission declared by that operation; authentication does not replace tenant, region, role, or entitlement checks.
  3. Call the operation through the documented API origin and retain the request ID and route ID returned by the response or error envelope.
  4. For a mutation, create one stable idempotency key for one intended change and reuse it only when retrying that same change.
  5. Respect the typed retry decision and retry budget; reconcile or use the documented dead-letter recovery path instead of looping indefinitely.
bash

Public liveness probe

Swipe or scroll horizontally to read the complete example.

curl --request GET '<api_origin>/api/healthz'

The authoritative API catalog defines GET /api/healthz as a minimal liveness probe with no tenant data and no mutation. Replace only the API origin.

bash

Public readiness probe

Swipe or scroll horizontally to read the complete example.

curl --request GET '<api_origin>/api/readyz'

The authoritative API catalog defines GET /api/readyz as a minimal readiness probe with no dependency details, tenant data, or mutation.

bash

Authenticated ticket list

Swipe or scroll horizontally to read the complete example.

curl --request GET '<api_origin>/api/v1/psa/tickets' --header 'Authorization: Bearer <access_token>'

The internal route catalog identifies this exact path as ticket.list. This public guide does not publish its request schema, credential setup, tenant context, permissions, filters, or release status; verify those before implementation.

Questions, answered

API evaluation guide: common questions

Which authentication scheme do I use?

Use the scheme declared by the operation. Customer integrations use the scoped credential path shown in their reference; agents, services, and provider callbacks use their declared mTLS or signature contract.

When can a failed request be retried?

Retry only when the typed error marks the failure retryable. Respect retry_after_seconds, keep the same idempotency key for the same intended mutation, and stop at the documented retry budget.

What should I retain for troubleshooting?

Retain the operation or route ID, request ID, timestamp, HTTP status, retryability, and content-safe integration context. Never log access tokens, webhook secrets, or customer payloads unnecessarily.