> ## Documentation Index > Fetch the complete documentation index at: https://www.composer.id/llms.txt > Use this file to discover all available pages before exploring further. # Gatekeeper > Gatekeeper (Signature & Contract Management): the API posture, publish target and field mapping composerID publishes a decision reference through. 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 ## 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. | 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. | | 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. | | 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. | | 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. | | 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 The five ways composerID reaches a destination, and the minimum a destination must offer. Plan, preflight and publish: how a decision becomes a valid record in a destination. Every destination composerID documents, with its category and coverage status.