Skip to content

Companies & Users

Every action on the GIB platform is attributed to a User. Every User belongs to a Company (the fintech operating through GIB). Authorization, audit logging, role-based access control, and the per-program submission constraint all hang off this two-level model.

Understanding this model is foundational, the rest of the data model uses these as anchors. The Users API, Companies API, and Session API cover create / list / update for these records and key-validation via getSessionInfo.

Company

A Company represents your fintech in GIB's system. It anchors:

A program (in operational shorthand) is the Company's overall integration with GIB. Throughout this documentation, "your program" and "your Company" are used interchangeably.

User

A User is an actor, a person or programmatic identity, that can sign in to the dashboard and / or hold an API key. Each User is attributed to a Company.

User attributes:

  • Identity: name, email, login credentials
  • Roles: see Roles & Permissions below
  • API keys: zero or more, each with its own IP allowlist and expiration
  • Audit trail: every action this User takes is logged with the User's identity

The submission constraint

Only one User per Company is permitted to submit transactions. This is a foundational program-level constraint. Choose this User carefully and document the reassignment process internally.

If you have multiple environments (CI, staging, production), use multiple Companies (one per environment) rather than trying to assign multiple submitters to one Company.

Roles & Permissions

GIB uses role-based access control (RBAC). The role assigned to a User determines which endpoints can be called and which resources can be acted on. The available roles are administered by GIB; retrieve the catalog via getRBACRoles.

When a User holds an API key, the key inherits that User's role. Revoking the User revokes their keys.

API key management

API keys are created and managed through the GIB Dashboard, not through the API. You must log in to the dashboard (with MFA) to provision your first key. There is no bootstrapping path via API since you need a key to call the API in the first place. Use the dashboard for all subsequent key creation, rotation, and revocation as well. See Security → Authentication for the full key lifecycle.

  • Subclients, the end users of your program
  • Security, authentication, IP allowlisting, key rotation
  • Idempotency, keys are User-attributed
  • Errors, 403 PermissionError when a User's role doesn't permit an action