generated: '2026-08-27' method: searched source: >- https://www.matilogistics.com/api (published API Reference, read 2026-08-27), https://www.matilogistics.com/track-trace (pricing + FAQ), and live probes of https://api.matilogistics.com. There is no OpenAPI, so no assertion below was derived from a machine-readable contract — each one cites the exact place in the provider's own surface that supports it, or records that nothing supports it. provider: Mati Logistics providerId: matilogistics docs: https://www.matilogistics.com/api contract_discovery: note: >- Recorded here because there is no openapi/ directory to record it in. STEP 0b contract discovery was run in full against every host on 2026-08-27 and every candidate missed. The API host is live and healthy — GET / returns {"service":"tnt_api","docs":null} and GET /health returns {"status":"ok"} — and it is a FastAPI/uvicorn service, which normally self-serves /openapi.json and /docs. Both are switched off. The `docs: null` field on the service root is the provider stating, in its own machine-readable response, that it publishes no descriptor. result: no published machine-readable contract probes: - {url: 'https://api.matilogistics.com/', status: 200, note: '{"service":"tnt_api","docs":null}'} - {url: 'https://api.matilogistics.com/health', status: 200, note: '{"status":"ok"}'} - {url: 'https://api.matilogistics.com/openapi.json', status: 404} - {url: 'https://api.matilogistics.com/openapi.yaml', status: 404} - {url: 'https://api.matilogistics.com/openapi', status: 404} - {url: 'https://api.matilogistics.com/swagger.json', status: 404} - {url: 'https://api.matilogistics.com/v2/openapi.json', status: 404} - {url: 'https://api.matilogistics.com/v2/swagger.json', status: 404} - {url: 'https://api.matilogistics.com/api-docs', status: 404} - {url: 'https://api.matilogistics.com/docs', status: 404} - {url: 'https://api.matilogistics.com/v2/docs', status: 404} - {url: 'https://api.matilogistics.com/redoc', status: 404} - {url: 'https://api.matilogistics.com/v2/redoc', status: 404} - {url: 'https://api.matilogistics.com/schema', status: 404} - {url: 'https://api.matilogistics.com/v2/schema', status: 404} - {url: 'https://api.matilogistics.com/spec', status: 404} - {url: 'https://api.matilogistics.com/graphql', status: 404, note: 'JSON not_found envelope, not a GraphQL error — no GraphQL surface'} - {url: 'https://api.matilogistics.com/mcp', status: 404} - {url: 'https://api.matilogistics.com/?wsdl', status: 200, note: 'returns the service-root JSON, not a WSDL — no SOAP surface'} - {url: 'https://www.matilogistics.com/openapi.json', status: 404} - {url: 'https://www.matilogistics.com/apis.json', status: 404, note: 'the apis.json declared at submission is not served'} - {url: 'https://www.matilogistics.com/llms.txt', status: 404} - {url: 'https://docs.matilogistics.com/', status: 0, note: 'host does not resolve'} - {url: 'https://status.matilogistics.com/', status: 0, note: 'host does not resolve'} standards: - id: bearer-token-auth conforms: true evidence: >- RFC 6750-style bearer token in the Authorization header on every request (https://www.matilogistics.com/api, "Authentication"). - id: oauth2 conforms: false evidence: >- No OAuth flow documented and no authorization-server metadata served (https://api.matilogistics.com/.well-known/oauth-authorization-server, 404). API keys only. - id: oidc conforms: false evidence: 'No /.well-known/openid-configuration on any host (404 on all three).' - id: rfc9457 conforms: false evidence: >- Errors use a bespoke {"error":{"code","message","request_id"}} envelope with content-type application/json, not application/problem+json (errors/matilogistics-problem-types.yml). - id: pagination conforms: true evidence: >- Cursor pagination on list endpoints via ?cursor= with meta.next_cursor and meta.has_more (https://www.matilogistics.com/api, "Pagination"). - id: idempotency conforms: false evidence: >- No Idempotency-Key header or equivalent. Resubmitting a reference is documented as an upsert on that reference, which is resource-level convergence rather than a general idempotency facility, and it does not cover webhook writes. See conventions/matilogistics-conventions.yml. - id: webhook-signing conforms: true evidence: >- HMAC-SHA256 over the raw request body, hex-encoded, in X-TNT-Signature, with a per-endpoint secret and a rotate_secret operation (https://www.matilogistics.com/api, "Verifying a delivery"). - id: rfc8594-sunset-deprecation conforms: false evidence: No deprecation or sunset policy published; no Sunset/Deprecation headers documented. - id: rfc9116-security-txt conforms: false evidence: '/.well-known/security.txt returns 404 on all three hosts (probed 2026-08-27).' - id: rfc8615-well-known conforms: false evidence: 'No /.well-known/ document of any kind is served (well-known/matilogistics-well-known.yml).' - id: iso-8601 conforms: partial evidence: >- Timestamps are ISO 8601, but a trailing Z is documented as "a storage convention, not a claim about UTC" when eventTimeIsLocal is true. The values are ISO-shaped; the offset is deliberately not authoritative. This is honest and well-documented, but it means a naive ISO 8601 consumer will mis-render carrier local times. - id: openapi conforms: false evidence: See contract_discovery above — 20+ candidate paths probed, all 404. - id: asyncapi conforms: false evidence: >- A real signed webhook surface exists with five documented event types, but no AsyncAPI document and no published delivery payload schemas (asyncapi/matilogistics-webhooks.yml). - id: mcp conforms: false evidence: 'No MCP server. https://api.matilogistics.com/mcp returns 404.' - id: a2a conforms: false evidence: 'No agent card at /.well-known/agent-card.json or /.well-known/agent.json on any host (404).' domain_standards: market: Ocean freight container visibility (track and trace) regulatory_regime: >- None. The Kin Score industry->regime map in scoring.yml carries no logistics or supply-chain regime, so no conditional regulatory facet applies to this provider. Recorded rather than force-fitted to an adjacent regime. signatures: - id: iso-6346 name: ISO 6346 — Freight containers, coding, identification and marking declared: true conforms: true strength: strong where: >- Named explicitly in the reference and ENFORCED at the contract boundary: under request_type "auto" the reference is classified "container by ISO 6346 shape and check digit", and "a reference whose shape is invalid, such as one with an incorrect check digit, is rejected with 422 naming the reason before any carrier is queried". The container owner prefix is also used as a carrier-detection stage. evidence: 'https://www.matilogistics.com/api — Quickstart and "Finding the carrier".' buyer_impact: >- An integrator already holding ISO 6346 container numbers can submit them unchanged and get validation feedback before any billable carrier lookup. - id: scac name: SCAC — Standard Carrier Alpha Code (NMFTA) declared: true conforms: true strength: strong where: >- `scac` is a first-class field on tracking_request and on the detection response; the `carrier` hint accepts a SCAC ("MAEU"); the published coverage table lists a SCAC for all 24 supported carriers and NVOCCs; and GET /v2/carriers is documented as the machine-readable source of that table. Bill-of-lading carrier detection is by SCAC prefix. evidence: 'https://www.matilogistics.com/api — "Finding the carrier", "Carrier coverage".' buyer_impact: >- A TMS or ERP already keyed on SCAC needs no carrier-name mapping table. - id: dcsa-track-and-trace name: DCSA Track & Trace (Digital Container Shipping Association) declared: false conforms: false strength: n/a where: >- THE NOTABLE ABSENCE. DCSA publishes the industry standard event model for exactly this product — Track & Trace with eventType TRANSPORT/EQUIPMENT/ SHIPMENT and eventClassifierCode ACT/PLN/EST — and every major carrier Mati aggregates (Maersk, MSC, CMA CGM, Hapag-Lloyd, ONE, Evergreen, HMM, OOCL, ZIM, Yang Ming) is a DCSA member. Mati normalizes carrier events into its OWN vocabulary instead: milestoneCode values such as VESSEL_DEPARTURE, TRANSSHIPMENT_DISCHARGE and GATE_OUT_DELIVERY, plus a separate shipment `tags` vocabulary. DCSA is named nowhere in the reference, and no mapping to it is published. evidence: >- https://www.matilogistics.com/api — the "Milestones" section lists the complete normalized vocabulary; it is bespoke. Searched the full reference text for "DCSA": no occurrence. buyer_impact: >- This is the bilateral-connector case the domain_standard check exists to expose. A buyer whose systems already speak DCSA cannot drop Mati in; they must write and maintain a milestone crosswalk. Publishing a DCSA mapping — even as a lookup table — would be the single highest-value interoperability move available to this provider. - id: un-locode name: UN/LOCODE — United Nations Code for Trade and Transport Locations declared: false conforms: unknown strength: n/a where: >- route[] points carry a `location_code` field, but the reference does not state which scheme it uses and every published example shows it as null. Locations are otherwise free text ("Chittagong", "Los Angeles, CA", "TANGER MED"). Not asserted either way. evidence: 'https://www.matilogistics.com/api — "Route".' - id: edifact-iftsta name: UN/EDIFACT IFTSTA (multimodal status report) declared: false conforms: false strength: n/a where: No EDI surface of any kind is offered or mentioned. evidence: >- Full-text search of the rendered reference at https://www.matilogistics.com/api on 2026-08-27: no occurrence of "EDIFACT" or "X12". JSON over HTTPS is the only transport offered. compliance_certifications: published: false note: >- No trust centre, no SOC 2 / ISO 27001 / PCI / HIPAA claim, and no security page anywhere on the site. /security, /terms, /privacy and /legal all return 404. probe-security-programs.py found no vulnerability-disclosure programme and no trust centre. No Compliance pointer is emitted. probes: - {url: 'https://www.matilogistics.com/security', status: 404} - {url: 'https://www.matilogistics.com/terms', status: 404} - {url: 'https://www.matilogistics.com/privacy', status: 404}