> ## 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.
# Tonkean
> Tonkean (Procurement Orchestration): the API posture, publish target and field mapping composerID publishes a decision reference through.
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
## 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.
| 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. |
| 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. |
| 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
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.