Check

Check represents a paper cheque instrument within the Well financial graph. It captures the identifying information printed on a physical cheque — the CMC7 magnetic-ink line, the check number, and the issue date — and ties the instrument to either a Company or a Person (the cheque holder) and to the Workspace that owns the record. Checks are referenced by PaymentMeans rows so that a payment settled by cheque can link back to the originating instrument.

Naming	Value
Object	Check
Resource type (JSON:API `type`)	`check`
Collection / records root	`checks`
REST base	`/v1/checks`
Entity class	`Check`

API operations

Operation	Method & path	Status
List	`GET /v1/checks`	✅ Implemented
Retrieve	`GET /v1/checks/{id}`	✅ Implemented
Create	`POST /v1/checks`	🟡 Planned
Update	`PATCH /v1/checks/{id}`	🟡 Planned
Delete	`DELETE /v1/checks/{id}`	🟡 Planned

Data model

Attributes

Field	Type	Required	Constraints	Allowed values	Description
check_id	string, UUID, 🔒 system	✅ Yes	unique; generated by gen_random_uuid() on INSERT	—	Public immutable identifier for the check. Used in all API responses and external references. Never expose the internal pk.
cmc7	string	⚪ No	max length 35; nullable	—	CMC7 magnetic-ink character recognition line printed at the bottom of the cheque. Encodes: 7-digit check number, 12-digit bank/branch code, 11-digit account number, 2-digit check key. Format is bank-dependent; no application-level regex is enforced.
check_number	string	⚪ No	max length 20; nullable	—	Human-readable check number as printed on the instrument (the sequential identifier within a cheque book). Used as the sort proxy for the composite_checks_list composite.
issue_date	date (YYYY-MM-DD)	⚪ No	nullable; stored as PostgreSQL date (no time component)	—	The date the cheque was issued (written), as declared on the instrument. Distinct from any settlement or booking date on an associated transaction.
created_at	datetime, 🔒 system	✅ Yes	set on INSERT via onCreate lifecycle hook; not nullable	—	Timestamp of record creation in the Well database. Set automatically; not editable by callers.
updated_at	datetime, 🔒 system	⚪ No	set on INSERT and on every UPDATE via onUpdate lifecycle hook; nullable (null until first update on legacy rows)	—	Timestamp of the most recent mutation. Managed by MikroORM lifecycle hooks.
deleted_at	datetime	⚪ No	nullable; null means record is active	—	Soft-delete sentinel. When set, the record is logically deleted and must be excluded from all queries (WHERE deleted_at IS NULL). Hasura select_permissions enforce this gate automatically for the user role.

Relationships

Name	Type	Required	Description
company	to-one (company)	No — mutually exclusive with people; at most one of the two is set	The Company that holds or issued this cheque. Stored as company_pk FK. Either company or people is set, never both — the entity comment documents this constraint as a business rule enforced at the application layer.
people	to-one (people)	No — mutually exclusive with company; at most one of the two is set	The Person who holds or issued this cheque. Stored as people_pk FK. Mutually exclusive with company at the business-rule level.
workspace	to-one (workspace)	No (nullable FK) — effectively required for any workspace-scoped use	The Workspace that owns this check record. Used by Hasura RLS to tenant-isolate query results via X-Hasura-Workspace-Id header. Stored as workspace_pk FK.
payment_means	to-many (payment_means)	No	The PaymentMeans rows that reference this cheque instrument via check_pk FK. A single Check may be referenced by multiple payment means (e.g. if re-presented or recorded across multiple contexts). The inverse FK lives on payment_means; checks.payment_means is a Hasura array_relationship only — there is no @OneToMany decorator in the MikroORM entity.

System-computed

check_id is generated by PostgreSQL gen_random_uuid() on INSERT and exposed as the public identifier; the internal auto-increment pk is never surfaced in API responses.
created_at is set automatically by the MikroORM onCreate lifecycle hook on INSERT.
updated_at is set by both onCreate and onUpdate lifecycle hooks, reflecting the timestamp of the most recent write.
deleted_at is managed by application-layer soft-delete logic; Hasura select_permissions for the user role enforce deleted_at IS NULL at the query layer so soft-deleted checks are never returned to end users.
The company / people mutual-exclusion constraint (checkholder is either a Company OR a Person, not both) is a business-rule invariant documented in the entity source; no DB-level CHECK enforces it — enforcement is at the service/application layer.
Workspace scoping is enforced by Hasura RLS: the user-role filter requires workspace.workspace_id = X-Hasura-Workspace-Id (direct) or workspace.workspace.workspace_id = X-Hasura-Workspace-Id (child workspace), with workspace_group membership paths for consolidated-view contexts.
The composite_checks_list composite (used when Check appears as a relation on Company or People records pages) is defined in composites.yml and surfaces check_id, check_number, and issue_date as source_fields with display_type: relation_list and is editable.
On Company and People records roots the Check appears as a composite_checks_list array field sorted by checks_aggregate.min.check_number.
On the checks records root, company and people checkholder composites (company.composite_logo_name, people.composite_avatar_fullname) and workspace composites are defined in composites.yml, along with composite_payment_means_list.

Example

{
  "data": {
    "type": "check",
    "id": "c3f4a2e1-8b7d-4c09-a5f6-1d2e3f4a5b6c",
    "attributes": {
      "check_id": "c3f4a2e1-8b7d-4c09-a5f6-1d2e3f4a5b6c",
      "cmc7": "7654321012345678901234567890123",
      "check_number": "000123",
      "issue_date": "2026-01-15",
      "created_at": "2026-01-15T09:30:00.000Z",
      "updated_at": "2026-01-15T09:30:00.000Z",
      "deleted_at": null
    },
    "relationships": {
      "company": {
        "data": { "type": "company", "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890" }
      },
      "people": {
        "data": null
      },
      "workspace": {
        "data": { "type": "workspace", "id": "w9x8y7z6-a5b4-c3d2-e1f0-g9h8i7j6k5l4" }
      },
      "payment_means": {
        "data": [
          { "type": "payment_means", "id": "pm-uuid-0001-0002-0003-000400050006" }
        ]
      }
    }
  }
}

_{Source: apps/api/src/database/entities/Check.ts · domain: financial-graph · tier: Supporting}

Main objects

Supporting objects

Platform objects

Activity objects

Infrastructure objects

API operations

Data model

Attributes

Relationships

System-computed

Example

​API operations

​Data model

​Attributes

​Relationships

​System-computed

​Example

API operations

Data model

Attributes

Relationships

System-computed

Example