Skip to main content

Core Concepts

Welcome to Oho's Core Concepts documentation. This section explains the fundamental building blocks of the Oho platform and how they work together to manage compliance, background screening, and workforce verification.

Understanding Oho's Data Model

Oho is built around three primary entities—Organizations, Constituents, and Accreditations. These entities form the foundation of how data is structured, stored, and accessed within the platform.

Think of these as the "primitive types" that everything else in Oho is built upon:

  • Organizations represent the companies, institutions, or entities using Oho
  • Constituents represent the individual people who require background checks or compliance screening
  • Accreditations represent the actual background checks, verifications, and compliance records

The Three Primitive Types

Organizations

Organizations are the top-level container in Oho's hierarchy. Every other entity exists within the context of an organization.

  • Acts as the tenant boundary for multi-tenancy
  • Provides data isolation between different customers
  • Serves as the billing entity for API usage
  • Defines the security context for all operations

Learn more about Organizations →

Constituents

Constituents are the individuals being screened or verified. They represent staff members, volunteers, contractors, or any person who requires background checks.

  • Stores personal information (name, date of birth, contact details)
  • Acts as the subject of background checks
  • Links to multiple accreditations over time
  • Belongs to exactly one organization

Learn more about Constituents →

Accreditations

Accreditations are the verification records themselves—the background checks, compliance verifications, and clearance records.

  • Represents a specific verification (WWC, NDIS screening, etc.)
  • Contains results and status from government registries
  • Always linked to a constituent via a claim
  • Tracks lifecycle and expiry information
  • Can be claimed by multiple constituents across different organizations

Learn more about Accreditations →

How They Work Together

These three entities form a relationship model:

Organization (Your Company)
├── Constituents (People)
│ └── Claims (Links to Accreditations)
│ └── Accreditations (Verification Records)
├── API Credentials
└── Webhooks

Accreditations (exist independently)
└── Can be claimed by multiple constituents across organizations

Key Relationships:

  • One organization has many constituents (1:N)
  • One constituent has many claims to accreditations (1:N)
  • One accreditation can have many claims from different constituents (N:M)
  • Accreditations exist independently and are linked to constituents via claims

Data Isolation

Each organization's data is completely isolated from other organizations. When you make API calls:

  1. Your authentication token identifies your organization
  2. All queries are scoped to your organization only
  3. You can never access another organization's constituents or accreditations
  4. This ensures complete data privacy and security

Common Workflows

Onboarding a New Employee

1. Create Constituent
POST /constituents
→ Person record created

2. Submit Background Check
POST /api/scan/{type}
→ Accreditation created (linked to constituent)

3. Receive Webhook
→ Accreditation status updated to "completed"

4. Verify Compliance
GET /constituents/{id}
→ View all accreditations for the person

Running a Bulk Compliance Audit

1. List All Constituents
GET /constituents
→ Retrieve all staff in your organization

2. Check Accreditation Status
→ Identify expired or missing checks

3. Submit New Checks (if needed)
POST /api/scan/{type} (for each)
→ Create new accreditations and link via claims

4. Generate Compliance Report
→ Export data showing organizational compliance

Why This Matters

Understanding these core concepts helps you:

  • Design better integrations - Know which endpoints to use and when
  • Structure your data correctly - Use the right entity for the right purpose
  • Implement workflows efficiently - Follow Oho's intended data model
  • Troubleshoot effectively - Understand relationships when debugging
  • Scale your usage - Plan for growth with the proper data architecture

What's Next?

Ready to dive deeper? Explore each concept in detail:

Or jump into practical implementation:

Need Help?

If you have questions about how these concepts apply to your specific use case, please reach out via GitHub or contact support@weareoho.com.