Gatekeeper (platform)

Gatekeeper is a vendor and contract lifecycle platform whose data model gives suppliers equal standing with contracts, wrapped in a Kanban workflow engine. Publishing into it usually means resolving or creating the vendor first, then the contract - and often raising a workflow card rather than writing to the repository directly. Gatekeeper is the system of record and execution for a decision taken upstream; what makes it different from a pure CLM is that the counterparty is a first-class object, not a field on the contract.

API at a glance Minimum viable mapping Custom fields & tenant mapping

Publish path

Direct API

composerID adapter → Gatekeeper API

Events back

Push events

native webhooks / events back

API access

Confirm licence

gated docs; API access may be a separate SKU

Contract tier

Tier A

full loop: publish + events back

Tenant configuration (mandatory fields, approval chains, picklists) is a separate gate from vendor capability: it is discovered at preflight before first publish and may need destination admin changes. How composerID connects →

Reference

API at a glance

The public API facts composerID's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.

Authentication	An API key issued per tenant, presented as a bearer token in the Authorization header. Keys are generated under the tenant's configuration settings and carry per-endpoint permissions, so calling an endpoint the key has not been granted returns an error - a publish key must be granted exactly the vendor, contract, custom-data and webhook endpoints it needs.
API style	REST over HTTPS following the JSON:API specification. Custom data groups configured in the tenant are exposed through the API, and the API reference adapts automatically as that custom data changes - so the callable field set genuinely differs tenant to tenant.
Base URL	Tenant subdomain: https://{subdomain}.gatekeeperhq.com/api/ - the authoritative endpoint reference lives inside the tenant itself at /api_docs
Objects	Suppliers and vendors alongside contracts as the two first-class records, plus workflow cards on the Kanban engine, custom data groups and fields, events and webhooks.
Events / webhooks	Native webhooks, documented in the knowledgebase: each webhook can send notifications for one or many events to the same endpoint, for example firing when a vendor record is updated, and events are included on all plans. Payload schemas, signature verification and retry behaviour are not published, so confirm them against the tenant's own reference.
Rate limits	None published. Assume limits exist and confirm against the tenant's own API reference before designing a bulk publish.

Developer access

The Gatekeeper API details are for registered developers

Auth model, base URLs, event posture and rate limits, free with a developer account.

Get free access → Registered developers are recognised automatically.

Readiness

Docs confidence: Customer

“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary, especially around custom fields, approval flows and object extensions.

Deterministic mapping

Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).

Tenant discovery

composerID can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.

Enrichment loop

If the target platform requires a field the Intent record doesn't yet have, composerID emits an enrichment_request back to the intake layer.

Mapping

Minimum viable mapping for Gatekeeper

An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.

Object	Canonical fields	Platform target	Required status	Notes
Supplier / vendor A first-class record; a contract normally hangs off one, so resolve-or-create the vendor before publishing the contract	counterparty	Supplier / vendor record	Required	This is the mapping difference versus a pure CLM. Agree a matching strategy per customer - duplicate vendor creation is the main publish risk on this platform.
Contract The contract record created in the repository as the execution artefact of the decision	title, owner	Contract title, plus internal owner and vendor-side owner	Required	Gatekeeper models two owner roles - an internal subject-matter expert and a counterparty-side contact. composerID's owner maps to the internal one; confirm whether the vendor-side owner must also be supplied.
Contract → dates Date fields drive dashboards, expiry metrics and automated renewal workflows, so date quality matters more than in a passive repository	start_date, end_date	Start date, and either an end date or an evergreen indicator with its notice terms	Required	End date and the evergreen indicator are mutually exclusive - the publisher decides which it is asserting rather than sending both.
Contract → custom data field Carrier for the Intent ID	intent_id	A tenant-configured custom data field, exposed automatically through the API	Tenant required	Because custom data groups flow through to the API and its reference, a dedicated field is the documented-shaped route. No native external-reference field was verified, so reading that field back is how a publisher de-duplicates.
Workflow card The Kanban engine supports creating records from form data, with triggers, checklists and approvals	value, defence_file_ref	Workflow card fields, contract value, and an attachment or URL custom field	Tenant	Whether composerID should write a repository record directly or raise a workflow card is a per-customer design decision with governance consequences - confirm it before mapping.

Developer access

The field-level mapping is for registered developers

Object targets, canonical fields and the Intent ID carrier for Gatekeeper, free with a developer account.

Get free access → Registered developers are recognised automatically.

Idempotency & drift: publish + reconcileExpand

Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.

Tenant specifics

Custom fields & unique mapping

Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.

How scanning works

High-level flow

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)

Important: where this platform is tenant-definedExpand

Gatekeeper is deeply tenant-configured: custom data groups and fields, workflow phases, approval routines and notification rules are all defined per customer, and because the API and its reference adapt automatically to custom data, the field set genuinely differs between tenants. The base URL is the customer's own subdomain and the authoritative reference lives inside the tenant, which is also where the API key is displayed - so scoping this integration needs tenant access rather than a public portal. Confirm the vendor-matching rule, whether publishing should create a repository record or a workflow card, and the tenant's rate-limit behaviour before go-live.

Developer access

Tenant-mapping notes are for registered developers

Where Gatekeeper deployments differ tenant to tenant, and what to check before first publish.

Get free access → Registered developers are recognised automatically.

Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.

Back to Platforms How integrations work API reference