Tonkean

This page records how composerID publishes into Tonkean: 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. Tonkean is a process orchestration platform used as the intake front door for procurement and legal: a board holds Solutions made of Modules, each Module tracks Items with configurable Fields, and Items arrive through Forms, native integrations or a custom webhook Data Source. Module triggers route, approve and hand each Item off to the systems of record (P2P, CLM, VMS) through their own actions. composerID publishes the workforce decision as an Item on the customer’s intake Module by posting JSON to that Module’s custom webhook Data Source, with the Intent ID as the payload’s unique-identifier field, so the Item is created once, updated on repeat posts and stays traceable to the decision through every step Tonkean orchestrates.

Category: Procurement Orchestration. Coverage status: Specification mapped. Vendor documentation: gated (customer or SKU documentation). No developer portal is evident.

Integration path

How composerID connects to this destination, at a glance.

Step	Detail
Authentication	Access is administered inside the Tonkean board by a workspace admin or maker.
composerID publishes	Intake request (Module Item): Custom webhook Data Source (JSON POST) on the intake Module; alternatively a Create Form submission
Intent ID lands on	`module_item` `fields.intentId`, written into the destination record
Back-sync	Webhooks and polling: some lifecycle events are pushed, the rest are read on a schedule.

Vendor documentation

Tonkean Docs (product documentation: data sources, modules, actions)

Tonkean: integrations

Tonkean: platform overview

API posture

Aspect	Detail
Authentication	Access is administered inside the Tonkean board by a workspace admin or maker. The evident inbound surface is the custom webhook Data Source, whose URL is unique to the data source and acts as its credential; any additional header secret, and whether a general API key or OAuth flow exists, is indicative until confirmed at onboarding. No public OAuth or API-key reference is evident.
Style	Inbound publishing is a JSON POST to a custom webhook Data Source: Tonkean parses the payload keys into data-source Fields and creates or updates one Module Item per unique identifier. Reads back are through Business Reports and Item Interfaces in the product; a programmatic read of Items is indicative and no public endpoint reference is evident, so no paths are stated here.
Base URL	Multi-tenant SaaS at app.tonkean.com; the custom webhook Data Source URL is issued when the data source is created in the board. Regional hosting, if any, is confirmed at onboarding.
Webhooks	Outbound is workflow-authored rather than a stock subscription API: a Module trigger (Item created, Field changed, approval outcome) runs a custom HTTP action against the composerID endpoint with the Item’s fields, including the identifier, in the payload. Built and maintained per Module by the customer’s Tonkean maker; delivery, retry and signing behaviour are indicative until confirmed at onboarding.
Events posture	Webhooks and polling
Rate limits	Not publicly documented. Treat as fair-use with exponential backoff on 429; confirm limits with the workspace admin at onboarding.
Objects	Solutions, Modules, Items, Fields (manual, formula, data-source matched), Forms (create and update), Data Sources (native integrations, custom webhook, email intake), Triggers and Actions (including custom HTTP actions), Business Reports, Item Interfaces

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.

Intake request (Module Item)

Create the workforce or services intake Item

Mapping	Detail
Canonical to destination	role_title or service_summary, worker_type, start_date, end_date, budget, cost_center, requester, business_justification
Target	Custom webhook Data Source (JSON POST) on the intake Module; alternatively a Create Form submission
Requirement	Required
Notes	Payload keys become data-source Fields on the Module, so the field set is whatever the customer’s maker has built for that Solution. Indicative until confirmed at onboarding.

Intent ID correlation

Carry the Intent ID

Mapping	Detail
Canonical to destination	intent_id -> fields.intentId, intent_version
Target	Custom webhook Data Source unique-identifier field
Requirement	Required
Notes	Tonkean Module Items carry fields from their data source, so the carrier is a tenant-defined field on the intake module rather than a stock column. Indicative until the module’s field set is confirmed at onboarding. Because the identifier is the match key, repeat posts update the same Item instead of forking it, and the same value is a Field that Business Reports can filter on. Tonkean Item URLs are keyed by internal Item id, so the deep link is illustrative and the real link is resolved from the Item once read back. Indicative until confirmed at onboarding.

Status read-back

Close the loop

Mapping	Detail
Canonical to destination	item status, approval outcome, resulting PO, contract or requisition reference
Target	Module trigger -> custom HTTP action to the composerID endpoint
Requirement	Recommended
Notes	Outbound payload must include the identifier Field so composerID correlates without a lookup. Workflow-configured per Module; there is no stock event subscription.

Tonkean has no fixed intake schema: the intake Module, its Fields, its Forms and its custom webhook Data Source are built by the customer’s Tonkean maker, so the field map, the identifier field and the outbound HTTP action are agreed per board at onboarding. Only the tenant can confirm that the unique-identifier field is set on the Data Source before the first publish (otherwise every post creates a new Item), which Module the Item lands on, which downstream systems (P2P, CLM, VMS) that Module hands off to so the Intent ID travels in those actions, and whether any API key, additional webhook secret or regional host applies. No public endpoint reference or rate-limit page is evident, so hosts, limits and auth are confirmed with the workspace admin.

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

Tonkean Docs (product documentation: data sources, modules, actions)

Tonkean: integrations

Tonkean: platform overview

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Tonkean Docs (product documentation: data sources, modules, actions)

Tonkean: integrations

Tonkean: platform 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