Fairmarkit (platform)
Fairmarkit is an autonomous sourcing platform: a request arrives from a connected P2P or ERP requisition or from its own intake form, Fairmarkit turns it into a competitive RFQ or RFP event, recommends and invites suppliers, collects bids and returns the award to the system of record. It exposes REST APIs covering sourcing events, bids and suppliers to customers and integration partners, with the endpoint reference behind the customer login rather than on an open developer portal. composerID publishes a services sourcing request for a Triage decision and records the linkage to the resulting Fairmarkit request on its own side, moving the Intent ID onto the request's external reference or a custom intake field once the tenant confirms which slot is free.
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 | Per-tenant API credentials issued by Fairmarkit at onboarding, exchanged for a bearer token. The grant type (static API key or OAuth 2.0 client credentials) is indicative until confirmed at onboarding; the reference sits behind the customer login. |
|---|---|
| API style | REST, JSON |
| Base URL | Tenant-specific API host supplied at onboarding; no openly published base URL. |
| Objects | requests (sourcing intake, including auto-sourced tail-spend requests), sourcing events (RFQ / RFP), bids and quotes, awards, suppliers and supplier recommendations; requisition and PO references where a connected P2P supplies them |
| Events / webhooks | No openly published webhook subscription contract. Fairmarkit's P2P and ERP connectors return the award to the source requisition, but that hand-back is connector plumbing, not a subscribable event feed. Treat integration as poll-first on request and event status until a webhook contract is confirmed at onboarding. |
| Rate limits | Not published openly. Confirm limits and retry guidance at onboarding and apply exponential backoff on 429. |
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 |
|---|---|---|---|---|
| Sourcing request Open the services sourcing event |
service_category, scope.summary, deliverables[], budget, start_date, end_date, cost_center, requester | Request create; Fairmarkit converts the request into an RFQ / RFP event | Required | The request is Fairmarkit's intake object and the only thing composerID creates; Fairmarkit's own logic converts it into a competitive event and invites suppliers. Intake forms are tenant-configured, so the exact field names are indicative until confirmed at onboarding. |
| Intent ID correlation Carry the Intent ID |
intent_id -> request.external_reference (indicative), else a custom intake field; link-mode until the slot is confirmed | Client-supplied reference on the Request, the slot the P2P connectors fill with the source requisition number | Required | Fairmarkit requests carry the source requisition reference when fed by a P2P, so a client-supplied reference exists; its API name is not published openly and the field here is indicative. composerID records the request id against the Intent ID on its side (mode link) and stamps the reference once the tenant confirms the slot is not reserved for a live P2P requisition number; a custom intake field is the fallback. Deep link https://{tenant_host}/requests?search={external_id} (illustrative). |
| Supplier Resolve incumbents and preferred suppliers |
supplier_name, supplier_external_id, category | Supplier reads | Read scope only | Used to pin an incumbent or preferred supplier onto the request when the Triage decision names one; never creates suppliers. |
| Award read-back Close the loop |
event_status, awarded_supplier, awarded_amount, bid_count | Event, bid and award reads filtered by request | Read scope only | Poll on request and event status until a webhook contract is confirmed; the award, and any PO number the connected P2P returns, are recorded against the Intent ID on composerID's side. |
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
Only the tenant can tell us what the API reference actually says: Fairmarkit issues credentials and the endpoint reference per customer, so the auth grant, base host, request field names, rate limits and any webhook contract stated here are indicative until read at onboarding. Intake forms are configured per tenant, so agree at onboarding which request field receives the Intent ID (the client-supplied external reference if it is free, a custom intake field if that slot is reserved for a P2P requisition number) and confirm the field is searchable in the request list before flipping the carrier from link to stamp. Where Fairmarkit is fed by a connected P2P (Coupa, Ariba, Jaggaer, Ivalua), decide whether composerID publishes to Fairmarkit directly or to the P2P and lets the existing connector carry the reference through; never both, or one decision produces two sourcing events.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.