Interface areas currently described
These are capability areas, not an unconditionally available endpoint list. Names, fields, statuses and environments follow the approved documentation supplied after access review.
Rate search
After an interface is approved and connected, origin, destination, cargo, weight, dimensions and service requirements may be submitted to receive structured options returned by the business system. The caller must not invent or rewrite total charges.
Authorised shipment tracking
After an interface is approved and connected, tracking may be retrieved only for orders or shipments the caller is authorised to access, using business status codes with source and last-updated information.
Applications and support coordination
Controlled submission and status coordination may be assessed for service-provider, promotional-partnership and API applications and support tickets.
Approved AI tool calls
Smart assistance may call only allowlisted interfaces with authorisation checks and audit controls after the relevant capability is released and approved. Model output cannot replace API results or human review.
Suitable users and application information
Suitable for enterprise use cases involving batch queries, internal workflow integration or authorised data coordination. Applications should include company and contact details, use case, principal lanes, cargo types, intended calling pattern, required capability, technical contact and security requirements. The applicant should provide call volumes and frequency from actual business needs.
From application to production
Onboarding normally includes requirements confirmation, entity and access review, technical assessment, testing and validation, security checks, agreement confirmation and production approval. Applying does not automatically grant endpoint, sandbox or production access.
API contract and data rules
Approved documentation should define versioning, authentication, fields, units, currency, time zone, language, request IDs, idempotency, rate limits, timeouts, error codes and change policy. Charges must retain the currency, validity and breakdown returned by the API; unknown values are marked to be confirmed, not shown as zero or free.
Credentials, authorisation and data security
API keys and access tokens must remain in a controlled server environment and must not appear in browser or mobile code, public repositories or visible logs. Each call should authenticate and authorise the requester and apply least privilege, rate limits, audit controls and necessary data masking.
How planned capabilities are described
Order creation, labels, billing, reconciliation and Webhooks may be described as available only after endpoints, permissions, signature or replay protection, error handling, testing and approved documentation are complete. Until then they are not availability commitments.