Tonkean (platform)
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.
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 | 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. |
|---|---|
| API 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. |
| 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 |
| Events / 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. |
| Rate limits | Not publicly documented. Treat as fair-use with exponential backoff on 429; confirm limits with the workspace admin at onboarding. |
No developer portal evident. We could not find a public self-service developer portal or endpoint reference for this platform; the API posture above is drawn from the vendor's own integration material and is confirmed at onboarding.
“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.
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 |
|---|---|---|---|---|
| Intake request (Module Item) Create the workforce or services intake Item |
role_title or service_summary, worker_type, start_date, end_date, budget, cost_center, requester, business_justification | Custom webhook Data Source (JSON POST) on the intake Module; alternatively a Create Form submission | Required | 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 |
intent_id -> fields.intentId, intent_version | Custom webhook Data Source unique-identifier field | Required | 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 |
item status, approval outcome, resulting PO, contract or requisition reference | Module trigger -> custom HTTP action to the composerID endpoint | Recommended | Outbound payload must include the identifier Field so composerID correlates without a lookup. Workflow-configured per Module; there is no stock event subscription. |
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.
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
What gets produced
Portable artefacts
Important: where this platform is tenant-definedExpand
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.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.