Gatekeeper

This page records how composerID publishes into Gatekeeper: the vendor’s API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it. 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.

Category: Signature & Contract Management. Coverage status: Specification mapped. Vendor documentation: gated (customer or SKU documentation).

Integration path

How composerID connects to this destination, at a glance.

Step	Detail
Authentication	An API key issued per tenant, presented as a bearer token in the Authorization header.
composerID publishes	Supplier / vendor: Supplier / vendor record
Intent ID lands on	`contract` `customData.intentId`, written into the destination record
Back-sync	Webhooks: the destination pushes events; composerID verifies each delivery and lands it on the intent’s timeline.

Vendor documentation

Configuring the Gatekeeper API (auth, API keys, per-tenant reference)

Integrations, including webhooks

Configure custom data

Contract dates

Gatekeeper Interconnect - integration overview

API posture

Aspect	Detail
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.
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
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.
Events posture	Webhooks
Rate limits	None published. Assume limits exist and confirm against the tenant’s own API reference before designing a bulk publish.
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.

Publish target and field mapping

Each object below pairs the canonical intent fields with the destination’s own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.

Supplier / vendor

A first-class record; a contract normally hangs off one, so resolve-or-create the vendor before publishing the contract

Mapping	Detail
Canonical to destination	counterparty
Target	Supplier / vendor record
Requirement	Required
Notes	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

Mapping	Detail
Canonical to destination	title, owner
Target	Contract title, plus internal owner and vendor-side owner
Requirement	Required
Notes	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

Mapping	Detail
Canonical to destination	start_date, end_date
Target	Start date, and either an end date or an evergreen indicator with its notice terms
Requirement	Required
Notes	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

Mapping	Detail
Canonical to destination	intent_id
Target	A tenant-configured custom data field, exposed automatically through the API
Requirement	Tenant required
Notes	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

Mapping	Detail
Canonical to destination	value, defence_file_ref
Target	Workflow card fields, contract value, and an attachment or URL custom field
Requirement	Tenant
Notes	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.

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.

Next steps

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Configuring the Gatekeeper API (auth, API keys, per-tenant reference)

Integrations, including webhooks

Configure custom data

Contract dates

Gatekeeper Interconnect - integration overview

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Configuring the Gatekeeper API (auth, API keys, per-tenant reference)

Integrations, including webhooks

Configure custom data

Contract dates

Gatekeeper Interconnect - integration overview

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps