API Data Model

Andrew Anderson
Andrew Anderson
  • Updated

In this article, we will give you a simple overview of how the Athennian data is structured so that you can more efficiently understand and use our API. This is our public ERD / data model overview which is segmented into the 4 sections below.

Data Model

Athennian is an entity management tool which our customers use to primarily centralize, share, and otherwise manage all their entities (and related data). This improves various workflows for the following teams: legal, finance, tax, compliance, etc.

Access Data

Data Access Details
Profiles Optional:
Tertiary access via API
  • 0-1+ per access group.
  • Entity or person records/objects.
Access Groups


Secondary access via API

  • 0-1+ per key.


Primary access via API

  • 0-1+ per environment and use case.


Primary access via API

  • 0-1+ per customer.
  • Each is generally specific to a customer’s full Athennian data set and contains multiple profiles.
  • Sandbox:
    • Test data generally.
  •  Production:
    • Live data generally.

Collection Terms

There are generally varies types of each collection type below.

Collection Summary Details
Entity Primary hub of most data Data primarily relevant to an entity (entities, company, organization, etc).
  • Examples: ID, Name, Type, Country, Tax ID, etc.
  • Company Groups
    • Segment of entities (optional).
Person Secondary hub of most data

Data primarily relevant to a person (people, contacts, principals, etc).

Address Profile addresses Data primarily relevant to a master/source, profile address (addresses, etc).
  • “Shared Addresses” (UI) refers to an address affiliation.
  • Container
    • A group of profile addresses owned by each profile.
Registration Entity affiliation data Data primarily relevant to a registration (registration, etc).
  • Some general similarities to an Entity profile type.
  • See Notes below for ID/UID context.
Affiliation Collection connection Data primarily relevant to a relationship between a specific entity, person, address, registration, etc.
  • Target
    • Parent profile information. Always an Entity.
  • Participant
    • Child profile information. Generally a Person.

Collection Map

Collection Sub-collections
  • Affiliations
    • 0-1+
  • Affiliations
    • 0-1+
  • Addresses
    • 0-1+
Addresses Links to owner and container
  • Affiliation
    • 1 always
  • Entity
    • 1 always
  • Profiles
    • 1 of each type generally
  • Addresses
    • 0-1+
  • Registration
    • 0-1  only


  • IDs
    • Note that usually our IDs are unique to each datapoint.
    • However, Registrations have 2 IDs (ID and UID).
      • ID matches the entity ID.
      • UID is the registrations Unique ID. If NULL than it is the home registration.

😃 Thank you for visiting! Please let us know if you have any feedback regarding this information.