Skip to main content

Identity & Environment

Two endpoints resolve the context of an API session: which organisation owns the data, and which user (or virtual user, for client-credentials integrations) is making the call. Every integration should hit them at least once on boot — assignment fields like SalesRepresentative, audit fields, and any "show me my own data" UI all depend on knowing this context.

Your Organization​

Tribe CRM's data model centres on your organisation: every Customer, Supplier, Employee and Activity is a relationship that extends from it. The current organisation is exposed as a singleton via the Relationship_Organization_Identity collection — querying it without filters returns the identity record for the authenticated session.

GET/v1/odata/Relationship_Organization_Identity?$expand=Relation($select=ID)&$select=Name

Name is the organisation's display name; the expanded Relation.ID is the GUID you'll cross-reference whenever an entity ties back to "us". For the full reference of fields and relationships available on this entity, see Identities.

Current Employee​

GetCurrentEmployee() resolves the authenticated user to an Employee record. For an Authorization Code flow this is the human who logged in; for a Client Credentials flow it's the virtual user provisioned for the integration.

GET/v1/odata/GetCurrentEmployee()?$expand=Person

The expanded Person carries name and contact details. The returned Employee.ID is the value you'll assign to fields like SalesRepresentative when creating activities on behalf of the caller — without it, the API can't attribute the action to a user.

tip

The Postman tutorial Getting started with the Tribe API walks through both calls as part of the first authenticated request.