.png)
FedEx Integration Guide
Connect enterprise order, fulfillment, and customer-service systems to FedEx REST APIs for rating, address validation, shipment creation, pickup, tracking, and selected webhook notifications.
FedEx integration options at a glance
FedEx’s current developer platform is centered on REST APIs for authorization, address validation, rates and transit times, shipment creation, tracking, pickup, and service availability. FedEx also documents webhook-style notifications for selected shipment and tracking events, although coverage depends on the account, product, and event type. OAuth 2.0 provides access using application credentials and FedEx account context. Martini can obtain and refresh tokens, call FedEx APIs from workflows, validate and transform payloads, expose internal REST APIs, receive supported webhook notifications, and coordinate scheduled tracking synchronization with downstream systems.
| Integration point | Supported by FedEx? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | FedEx’s primary integration mechanism for Authorization, Address Validation, Rates and Transit Times, Ship, Track, Pickup, Service Availability, and eligible freight operations. | Martini can consume FedEx REST APIs from workflows, expose APIs for internal applications, transform JSON payloads, and apply business rules around shipping operations. |
| Webhooks / outbound callbacks | Limited | FedEx documents notifications for selected shipment and tracking events. Coverage depends on event type, product, subscription configuration, and account eligibility. | Martini can expose a webhook-facing API, validate and normalize notifications, deduplicate events, and route them to downstream workflows. |
| Authentication | Yes | FedEx REST access uses OAuth 2.0 application credentials, bearer access tokens, and FedEx account context where required. | Martini can store credentials as protected environment configuration, obtain tokens, reuse them during their validity period, and refresh them when needed. |
| SOAP APIs | Legacy | FedEx historically provided SOAP-based Web Services, but current developer materials emphasize REST APIs and new integrations should prefer REST where available. | Martini can consume SOAP services when a required legacy or product-specific operation remains available, subject to FedEx verification. |
| Bulk / asynchronous / batch APIs | Not confirmed | FedEx supports multi-package and shipment operations, but a general-purpose bulk REST API for all resources was not confirmed. | Martini can implement controlled batching, queue-based processing, throttling, and retries around the specific FedEx APIs exposed for the use case. |
| File / attachment APIs | Limited | Shipping operations may return labels or documents as encoded content or document references, but FedEx does not document a general-purpose file repository or attachment API. | Martini can process JSON, encoded document content, and files returned by supported operations while controlling storage and logging of large documents. |
| Scheduled synchronization | Yes | Scheduled tracking queries can support systems that do not use FedEx webhook notifications or need reconciliation of active shipments. | Martini can run scheduler-triggered workflows with checkpoints, throttling, idempotent updates, and controlled retry handling. |
How FedEx exposes data and business events
FedEx REST APIs
FedEx’s current developer catalog is centered on REST APIs for authorization, address validation, rates and transit times, shipment creation, tracking, pickup, and service availability. Available operations depend on the FedEx account, application configuration, and enabled APIs.
Martini implementation pattern
Martini implementation pattern: Martini workflows obtain or reuse an OAuth 2.0 token, construct FedEx requests from canonical fulfillment data, call the relevant REST operation, validate the response, and map the result to the source or target application. Martini APIs can provide a stable internal contract while FedEx-specific schemas remain inside reusable integration logic.
Implementation sequence
FedEx Webhooks
FedEx documents webhook functionality for selected shipment and tracking notifications. Notifications are not confirmed for every FedEx object or state transition, so event coverage and subscription requirements must be verified for the account and product.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled API endpoint for supported FedEx notifications, validates the request according to FedEx requirements, records a deterministic event key, and routes the normalized event to fulfillment, customer-service, or warehouse workflows. Downstream processing remains idempotent because notifications may need replay or reconciliation.
Implementation sequence
FedEx Scheduled Tracking
FedEx Track APIs can support scheduled synchronization for systems that do not use webhook notifications or require reconciliation of active shipments. Query design, result limits, and account permissions should be confirmed for the selected operation.
Martini implementation pattern
Martini implementation pattern: A scheduler-triggered workflow selects active Tracking Numbers, calls FedEx Track with controlled concurrency, maps status and exception data, and updates downstream systems only when the normalized state changes. Checkpoints and retry handling limit repeated requests and support recovery after an interrupted run.
Implementation sequence
FedEx SOAP Web Services
FedEx historically offered SOAP-based Web Services, while current developer materials emphasize REST APIs. SOAP should be treated as a legacy or product-specific mechanism and verified before implementation.
Martini implementation pattern
Martini implementation pattern: Where a required legacy FedEx operation remains available, Martini can consume the SOAP service, configure the required authentication and XML handling, transform the response into the same canonical model used by REST workflows, and isolate the legacy dependency for future migration.
Implementation sequence
Common FedEx integration patterns
Pattern 1: Create FedEx shipments from orders
When to use this pattern
Use this pattern when a commerce, order-management, or enterprise resource planning application needs to create FedEx shipments after an order or fulfillment is approved. Address, package, service, billing, and account rules should be validated before shipment creation, and uncertain responses require duplicate protection.
Integration direction
Example Mapping
| FedEx Field | Canonical Field | Target Field |
|---|---|---|
| recipient.address | destinationAddress | requestedShipment.recipient.address |
| fulfillment.packages[].weight | packages[].weight | requestedShipment.requestedPackageLineItems[].weight |
| shipping.service | serviceType | requestedShipment.serviceType |
| order.id | sourceFulfillmentId | clientReferenceId |
Martini implementation pattern
Martini receives the fulfillment request through an API or workflow trigger, validates the address and package model, obtains or reuses a FedEx OAuth token, calls the Ship API, and persists the Shipment, Tracking Number, and label result. A stable source fulfillment identifier and response store help the workflow determine whether a timed-out request may already have succeeded before retrying.
Martini capabilities used
- workflows
- API consumption
- API exposure
- data mapping
- business rules
- secrets management
- error handling
Pattern 2: Return FedEx Rate Quotes at checkout
When to use this pattern
Use this pattern when checkout or order-management applications need FedEx service choices and estimated costs before fulfillment. Business rules can suppress services that do not meet promised delivery dates, destination constraints, account rules, or cost thresholds.
Integration direction
Example Mapping
| FedEx Field | Canonical Field | Target Field |
|---|---|---|
| destination.postalCode | destinationPostalCode | requestedShipment.recipient.address.postalCode |
| packages[].dimensions | packageDimensions | requestedShipment.requestedPackageLineItems[].dimensions |
| packages[].weight | totalPackageWeight | requestedShipment.requestedPackageLineItems[].weight |
| rateReplyDetails[].ratedShipmentDetails.totalNetCharge | estimatedShippingCost | shippingOptions[].price |
Martini implementation pattern
Martini exposes a consistent rating API, maps the checkout request to FedEx Rates and Transit Times, normalizes returned Rate Quotes, and applies rules for service availability, delivery promises, and price presentation. Validation and controlled error responses prevent a transient FedEx issue from producing misleading checkout options.
Martini capabilities used
- API exposure
- API consumption
- data mapping
- transformations
- business rules
- error handling
Pattern 3: Synchronize FedEx tracking events
When to use this pattern
Use this pattern when order, support, warehouse, or customer-facing systems need current delivery milestones and exceptions. It supports selected FedEx webhook notifications and can be complemented by scheduled Track API reconciliation for active shipments.
Integration direction
Example Mapping
| FedEx Field | Canonical Field | Target Field |
|---|---|---|
| trackingNumber | trackingNumber | Shipment__c.Tracking_Number__c |
| eventType | deliveryStatus | Shipment__c.Status__c |
| scanLocation | lastKnownLocation | Shipment__c.Last_Location__c |
| eventDateTime | statusTimestamp | Shipment__c.Status_Timestamp__c |
Martini implementation pattern
Martini receives supported FedEx notifications through an API-facing workflow, validates and deduplicates them, and maps status changes to downstream shipment or case objects. A scheduled workflow can query active Tracking Numbers where webhooks are unavailable, while checkpoints, throttling, and idempotent writes handle replay and out-of-order delivery.
Martini capabilities used
- API exposure
- webhook consumption
- scheduled workflows
- data mapping
- idempotency rules
- error handling
- monitoring
Pattern 4: Validate addresses before fulfillment
When to use this pattern
Use this pattern when an application needs to reduce shipment failures caused by incomplete or invalid destination data. The workflow can return a normalized address, a correction recommendation, or a controlled rejection before the FedEx Ship API is called.
Integration direction
Example Mapping
| FedEx Field | Canonical Field | Target Field |
|---|---|---|
| shippingAddress.street | streetAddress | addressToValidate.streetLines |
| shippingAddress.city | city | addressToValidate.city |
| shippingAddress.postalCode | postalCode | addressToValidate.postalCode |
| validationResult | addressValidationStatus | fulfillment.addressStatus |
Martini implementation pattern
Martini receives an Address, validates required fields, calls FedEx Address Validation, and maps the response into a stable internal result. Business rules can block fulfillment when validation fails or requires correction, while the workflow preserves FedEx messages for support and operational review.
Martini capabilities used
- API exposure
- API consumption
- data validation
- data mapping
- business rules
- controlled error responses
Applications commonly integrated with FedEx
FedEx can be integrated with commerce, enterprise resource planning, customer-service, and operational applications through their APIs or events together with FedEx REST APIs. The following are realistic architecture patterns; they do not imply a direct native integration supplied by FedEx.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Create FedEx shipments from paid orders and return tracking numbers, labels, and delivery updates to the order workflow. | Shopify → Martini → FedEx | Martini exposes an order-fulfillment API or consumes Shopify events, validates address and package data, calls FedEx Ship and optionally Rates APIs, then writes tracking and label information back to Shopify. |
| Salesforce | Synchronize shipment status, tracking numbers, and delivery exceptions with Accounts, Contacts, Cases, or custom fulfillment objects. | FedEx → Martini → Salesforce | Martini receives supported FedEx notifications or schedules Track API queries, maps delivery states to Salesforce objects, and applies idempotent updates while preserving FedEx identifiers. |
| NetSuite | Connect sales orders and item fulfillments to FedEx for rating, label creation, shipment processing, and tracking updates. | NetSuite → Martini → FedEx | A Martini workflow retrieves approved fulfillment data from NetSuite, validates package details, calls the relevant FedEx APIs, stores the Shipment and Tracking Number, and updates the fulfillment record. |
| SAP S/4HANA | Send outbound delivery and package information to FedEx and return shipment identifiers, documents, and status updates to SAP logistics processes. | SAP S/4HANA → Martini → FedEx | Martini consumes SAP delivery messages or APIs, transforms delivery and package structures into FedEx requests, processes the response, and routes tracking updates back to the relevant SAP delivery. |
| Microsoft Dynamics 365 | Use FedEx rating, shipping, tracking, and address validation in order fulfillment and customer-service processes. | Microsoft Dynamics 365 → Martini → FedEx | Martini orchestrates Dynamics 365 requests with FedEx REST calls, normalizes Rate Quotes and shipment responses, and returns a consistent fulfillment result with controlled retries. |
| Oracle NetSuite | Integrate fulfillment records and customer-facing tracking information with FedEx operations. | Oracle NetSuite → Martini → FedEx | Martini maps NetSuite fulfillment data to FedEx Ship and Track requests, stores correlation identifiers, and synchronizes status changes without creating duplicate shipments. |
| Zendesk | Push delivery status and exceptions into support cases so service agents can answer shipment questions using current tracking information. | FedEx → Martini → Zendesk | Martini normalizes FedEx tracking events, applies rules for exceptions and delivery milestones, and creates or updates Zendesk tickets through its supported API. |
| ServiceNow | Synchronize logistics exceptions and delivery incidents with operational workflows and service records. | FedEx → Martini → ServiceNow | Martini receives supported FedEx notifications or scheduled tracking results, maps exceptions to ServiceNow records, and routes updates through a reusable workflow with duplicate protection. |
How to build a FedEx integration in Martini
Objective
Establish separate FedEx test and production configurations using OAuth 2.0 application credentials, account numbers, endpoints, and protected environment settings.
Instructions in Martini
- Register or identify the FedEx application and enabled APIs
- Store client credentials and account context in protected configuration
- Configure separate test and production endpoints and credentials
- Implement token acquisition and reuse according to token validity
Objective
Select an API request, FedEx webhook notification, or scheduled workflow trigger based on the required fulfillment and tracking behavior.
Instructions in Martini
- Use an exposed Martini API for synchronous rating, address, or shipment requests
- Use a webhook-facing API for supported FedEx notifications
- Use a scheduler for tracking reconciliation or periodic operational synchronization
- Define correlation identifiers and checkpoint requirements
Objective
Receive source application data or retrieve current FedEx information with the appropriate REST operation and account context.
Instructions in Martini
- Validate the source payload before making a FedEx request
- Call Authorization, Address Validation, Rates, Ship, Track, or Pickup as required
- Retrieve current shipment details when a notification is incomplete
- Control concurrency and request frequency
Objective
Coordinate FedEx calls, source-system interactions, persistence, branching, and recovery in a maintainable Martini workflow.
Instructions in Martini
- Separate token acquisition, validation, API calls, mapping, and persistence into clear stages
- Route success, validation, account, rate-limit, and transient errors separately
- Use reusable integration logic for common FedEx request and response handling
- Queue or batch work when the business process does not require a synchronous response
Objective
Convert source application models and FedEx payloads into canonical shipment, package, address, rate, pickup, and tracking structures.
Instructions in Martini
- Map source order and fulfillment fields to FedEx request structures
- Normalize FedEx service, charge, status, and exception values
- Process labels or encoded documents only when returned by the selected operation
- Preserve FedEx identifiers and source correlation keys
Objective
Enforce fulfillment, service, address, account, delivery, and duplicate-prevention rules before committing changes.
Instructions in Martini
- Reject incomplete addresses or package measurements
- Select or suppress Rate Quotes according to cost and delivery rules
- Check for an existing Shipment or Tracking Number before retrying uncertain creation requests
- Apply idempotent event handling for notifications and scheduled updates
Common FedEx data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Shipment | Represents a shipping transaction with service, origin, destination, package, billing, and delivery instructions. | Shopify, NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Salesforce | Martini validates required fields, maps fulfillment data to FedEx shipment requests, persists correlation identifiers, and processes the resulting shipment response. |
| Package | Represents a physical parcel within a Shipment, including dimensions, weight, packaging, and tracking information. | NetSuite, SAP S/4HANA, Microsoft Dynamics 365, warehouse applications | Martini transforms package measurements and weights, validates required values, and applies business rules before shipment creation or rating. |
| Tracking Number | Identifies a shipment or package for movement, milestone, delivery, and exception tracking. | Shopify, Salesforce, Zendesk, ServiceNow, customer portals | Martini stores the identifier with the source fulfillment, uses it for webhook correlation or scheduled Track requests, and prevents duplicate downstream updates. |
| Rate Quote | Provides an estimated shipping cost and service option based on origin, destination, package characteristics, service type, and account details. | Shopify, Microsoft Dynamics 365, checkout services, order-management applications | Martini normalizes returned service, transit, and cost data and applies rules for promised dates, cost thresholds, destinations, and account policies. |
| Address | Represents an origin, destination, shipper, recipient, or pickup address used for validation and shipping. | Shopify, Salesforce, NetSuite, SAP S/4HANA, order-management applications | Martini maps source address models to FedEx Address Validation requests and returns a normalized result or controlled validation message. |
| Pickup | Represents a request or booking for FedEx to collect one or more packages. | Warehouse systems, NetSuite, SAP S/4HANA, Microsoft Dynamics 365 | Martini validates pickup details, calls the applicable FedEx Pickup API, persists the response, and routes failures according to operational rules. |
Authentication and security considerations
OAuth 2.0 and account context
FedEx REST APIs use application credentials to obtain time-limited OAuth 2.0 bearer tokens. Requests may also require the FedEx account number and permissions associated with the application and account.
Protected configuration
Store client IDs, client secrets, account numbers, endpoints, and environment-specific settings in protected Martini configuration. Keep test and production credentials separate and avoid placing tokens or secrets in logs.
Request protection
- Refresh or reacquire tokens before expiration.
- Validate webhook requests according to FedEx requirements before processing them.
- Restrict exposed Martini APIs with appropriate authentication and authorization.
- Limit access to shipment, address, customer, and label data according to operational need.
Operational considerations for FedEx integrations
Rate limits and account eligibility
FedEx limits, quotas, enabled APIs, service eligibility, and account permissions vary by application and account. Use controlled concurrency and verify the applicable FedEx documentation and terms.
Pagination and synchronization
Tracking and operational queries may require segmentation or bounded result handling. Use durable checkpoints where supported and do not rely on timestamps alone when events can arrive out of order.
Idempotency and retries
Persist source fulfillment identifiers, FedEx Shipment identifiers, and Tracking Numbers. Before retrying an uncertain shipment or label request, determine whether FedEx may already have accepted it. Apply backoff for transient failures and avoid repeated unchanged tracking queries.
Schema and document changes
Version mappings and validate required fields because FedEx service codes, schemas, error structures, and API versions can change. Confirm label encoding and media types before storing or forwarding documents, and keep large documents out of routine logs.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates FedEx authorization, address validation, rating, shipment creation, tracking, pickup, and downstream application updates in workflows rather than scattering logic across scripts.
Reusable integration assets
Expose a stable internal API for shipping capabilities while isolating FedEx-specific payloads, credentials, account rules, and service mappings inside reusable integration logic.
Reliable operations
Use mapping, validation, business rules, checkpointing, retries, duplicate protection, and monitoring consistently across synchronous shipment requests and asynchronous tracking synchronization.
Maintainable change management
Martini provides a structured place to version transformations and adapt to FedEx schema or service changes without requiring every connected application to implement FedEx behavior independently.
Frequently asked questions
FedEx can be integrated through its current REST APIs for authorization, address validation, rates and transit times, shipment creation, tracking, pickup, and service availability. FedEx also documents webhook notifications for selected shipment and tracking events. Enterprise systems can call these APIs directly or use Martini to expose a stable internal API, orchestrate workflows, map data, and synchronize results.
Yes. Martini can integrate with FedEx by consuming FedEx REST APIs, obtaining OAuth 2.0 tokens, sending account and shipment data, processing responses, and receiving supported FedEx webhook notifications. A scheduled workflow can also query Tracking for active shipments when webhooks are unavailable or reconciliation is required.
No dedicated FedEx connector is required. Martini can use FedEx’s confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authentication, selected webhook notifications, and legacy SOAP services when a required operation remains available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate FedEx. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from FedEx, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
The most common starting points are Authorization, Rates and Transit Times, Ship, Track, Address Validation, and Pickup. The appropriate combination depends on whether the process covers checkout rating, shipment creation, delivery visibility, address quality, or pickup scheduling. Current integrations should generally prefer REST APIs over legacy SOAP where the required operation is available.
Martini can receive FedEx webhook notifications where the customer’s account and selected FedEx services support them. FedEx webhook coverage is event- and product-specific, so it should not be assumed for every shipment or tracking transition. A scheduled Track workflow can provide a complementary synchronization method.
Martini maps source orders, fulfillments, addresses, and packages to FedEx request models, then normalizes Ship, Rate Quote, Pickup, and Tracking responses into target-specific structures. Synchronization can be event-driven through supported notifications or scheduled through Track queries, with checkpoints, correlation identifiers, and idempotent updates.
Martini workflows can separate authentication, validation, account eligibility, rate-limit, and transient failures, then apply controlled retry and backoff rules. Stable source fulfillment identifiers and stored FedEx responses help prevent duplicate shipments. Martini can also expose a REST API façade that hides FedEx-specific details from internal applications and provides a consistent error model.
Related Martini documentation
Workflows
Data processing
Connect FedEx to your enterprise workflows
Use Martini to orchestrate FedEx shipping, rating, address validation, pickup, and tracking processes across the applications that run your fulfillment and customer-service operations.