From a Simple API Integration to a Complete Online Courier Booking Workflow
Project Overview
A courier business approached Ranjit Singh through Fiverr in February 2023 with what initially appeared to be a straightforward requirement:
Integrate a third-party parcel delivery quotation API into their WordPress website.
The website was Courier.ie, and the requested API was provided by Norsk Global, a shipping and logistics platform.
The initial requirement was to connect the API with WordPress/PHP so customers could obtain parcel delivery quotes. However, as the integration progressed, the project expanded considerably.
What began as an API integration became a broader shipping workflow incorporating:
- Delivery-service quotation
- Shipment booking
- Shipment tracking
- Customer and consignee information
- Parcel dimensions and customs information
- WordPress/PHP integration
- Payment processing
- Stripe integration
- PayPal integration
- Currency conversion
- Business markup and fuel surcharge calculations
- Shipping-label access
- Carrier/service presentation
- Address suggestions
- Production deployment
- Debugging between the website, API and Norsk support team
The project became a practical example of how a third-party API integration can evolve into a complete business automation system.
The Initial Requirement
The client first contacted Ranjit on February 8, 2023, asking whether he could integrate a third-party parcel delivery quotation API into a WordPress website.
The first discussion focused on understanding the API, the website and the number of services required. The client provided the website and API documentation and initially expected several API services to be integrated.
The first service was estimated at $30, with subsequent services priced separately. At that stage, the client indicated that the same implementation could eventually be required for multiple websites.
The initial scope was therefore relatively simple:
WordPress website → PHP → Norsk API → shipping information
But the real complexity appeared once testing began.
The First Challenge: Working With a Third-Party API
The first integration was performed on a staging environment.
Instead of immediately building the complete customer-facing system, the implementation was approached service by service.
This allowed individual API functions to be tested before being incorporated into the larger workflow.
The first service became the foundation for the remaining integrations because other API functions depended on the same underlying communication and response handling.
This staged approach became important when the API credentials and test environment started returning errors.
For example, the staging API returned an authorization error indicating that the public key was invalid. Test shipment data also produced an unknown error.
Rather than treating the API documentation as sufficient, the project required real-world testing, API responses, and communication with the provider.
Working Between the Client and API Provider
One of the most important aspects of the project was that the developer was not working with only one system.
There were effectively three parties involved:
- Courier.ie — the business website
- Ranjit Singh — WordPress/PHP developer
- Norsk Global — third-party logistics API provider
When an API response could not be explained from the website side, the client communicated with Norsk support and passed the responses back to the developer.
This created an iterative debugging process:
Website request → Norsk API → API response → developer analysis → provider clarification → revised request → testing
A particularly important breakthrough occurred when Norsk explained that an attempted UPS shipment was using an export service incorrectly for the selected route. The consignee country and shipment direction did not match the service requirements.
After this information was applied, the integration began working for that scenario.
This demonstrated an important lesson:
Not every API error is a programming error.
Sometimes the problem is caused by business rules, service restrictions, account configuration or incorrect request parameters.
Moving Beyond the API
After the core API functions were working, the project moved from backend integration toward an actual customer-facing booking system.
The client wanted customers to be able to:
- Enter shipment information
- Obtain delivery quotes
- Select a shipping service
- Book the shipment
- Track the shipment
- Make payment
- Access the shipment label
The developer created functional forms for the quote, booking and tracking workflow.
At this point, the project was no longer simply an API connection.
It was becoming a complete shipping application inside WordPress.
Using an Existing Industry Workflow as a Reference
The client repeatedly referred to ParcelHero as an example of the type of customer experience they wanted.
The reasoning was practical: ParcelHero was also using Norsk’s services, so its workflow could serve as a useful reference for the customer journey.
The client asked for the new system to follow a similar pattern, including the presentation of shipping services and booking information.
This changed the nature of the project.
It was no longer enough for the API to technically work.
The output also needed to make sense to an actual customer.
Expanding the Booking Form
As real-world testing continued, additional fields were identified as important.
The booking workflow eventually needed information such as:
- Collection location
- Destination location
- City
- Postal code
- Parcel information
- Shipment details
- Customs information
- Export/import reasons
- HS code
- Country of origin
- Consignor information
- Consignee information
The client specifically requested additional city and postal-code fields after testing the form.
Later, the client also emphasized customs-related fields such as country of origin, export/import reasons, parcel description and HS code.
This is a common pattern in API projects:
The API documentation describes what the system can do; real users reveal what the interface actually needs.
Handling Difficult Shipping Routes
One of the most challenging parts of the project involved international routes.
Ireland-to-UK and UK-to-Ireland quotations did not always behave as expected.
At one stage, the system could return services for some routes but not others.
The developer tested different request parameters, reviewed API responses and worked with the client to obtain additional information from Norsk.
The client compared the expected results with ParcelHero, which was using the same underlying logistics provider. This gave the project a useful real-world benchmark.
The debugging process included examining request and response data rather than simply changing code blindly.
The developer also exposed request/response information during debugging so that the client could share precise technical information with Norsk’s support team.
This created a much more effective support loop.
Payment Gateway Integration
Once the quotation and booking workflow was taking shape, payment became the next major component.
The client already had access to:
- Stripe
- PayPal
The project therefore expanded to include payment processing.
The payment module was developed and tested in stages, initially using sandbox credentials. Later, the Stripe integration was moved to the live environment.
The client also wanted both Stripe and PayPal available rather than relying on a single payment provider.
This introduced another layer to the workflow:
Norsk quote → customer price → payment → successful booking → shipment label
Currency Conversion and Business Pricing
Another important business requirement emerged during payment integration.
Norsk’s prices were being returned in GBP, while the courier business operated in Ireland and wanted customers to see prices in EUR.
Simply displaying the API price was therefore insufficient.
The system needed to account for:
- Supplier/API price
- Currency conversion
- Business markup
- Additional surcharge
- Final customer price
The client specifically requested a mechanism for adding a margin to the supplier prices, as well as accounting for fuel surcharge.
A currency conversion API was subsequently introduced into the workflow so that GBP-based API prices could be converted for the customer’s EUR-facing experience.
This was a significant transition from a technical API integration to a business-pricing system.
The application was no longer simply showing what the carrier charged.
It was helping the courier business determine what its own customers should pay.
Shipment Labels and Post-Payment Experience
The project also needed to handle what happened after payment.
The client wanted customers to be able to access and print their shipment labels after successfully placing an order.
A label download link was added to the successful shipment-booking flow.
This completed an important part of the customer journey:
Get Quote → Select Service → Enter Shipment Details → Pay → Book Shipment → Access Label
That is substantially different from a simple “API integration.”
It is an end-to-end transaction workflow.
Improving the User Experience
The client wanted the interface to resemble established courier-booking platforms.
Several user-experience improvements were therefore introduced during the project:
- Carrier/service logos
- Estimated delivery information
- Additional form fields
- Address suggestions
- Payment-provider icons
- Pricing adjustments
- Shipment-label access
- Improved service presentation
The client specifically requested carrier logos and ETA information because competing services displayed these details. The developer explained that the API response itself did not provide the logos and therefore created a mapping mechanism for displaying them.
This is another important API-development lesson:
External APIs often provide data, not the complete presentation layer.
The application may need to build additional logic around the API to turn raw data into a useful customer experience.
Debugging in the Real Environment
The project encountered several issues that required investigation beyond ordinary coding.
Examples included:
- Invalid staging credentials
- API request errors
- Route/service restrictions
- Missing services for particular destinations
- Development-environment differences
- Payment configuration
- Currency mismatch
- Address validation
- API field requirements
- Carrier/service presentation
- Production configuration
At one point, the client reported that a route returned no services even though the provider’s own system showed available services.
Instead of assuming the problem was in the form, the developer compared requests and responses and continued working with Norsk’s technical team.
This approach helped isolate issues that were caused by API-side business rules rather than WordPress code.
From Staging to Production
The implementation eventually moved from the development/staging environment toward the production website.
The plugin was transferred to the production environment, and the quote and tracking pages were made available on the production setup.
The transition required additional production credentials and configuration, including the live payment environment.
This is an important distinction in API projects:
A system that works in a sandbox is not automatically production-ready.
Production deployment requires another round of testing, credentials, payment configuration, webhooks, pricing and customer-flow verification.
The Project’s Evolution
The project can be viewed in several stages.
Stage 1 — API Proof of Concept
The original requirement was simple:
Connect WordPress/PHP to Norsk Global API.
Stage 2 — Core Shipping Functions
The integration expanded to include:
- Quote
- Booking
- Tracking
Four of the planned services were initially implemented, while several less-immediate endpoints were postponed until they were required.
Stage 3 — Customer Booking Interface
The API was connected to functional WordPress forms so customers could interact with the system.
Stage 4 — Business Logic
The system began handling:
- Pricing
- Markup
- Fuel surcharge
- Currency conversion
- Service selection
Stage 5 — Payments
Stripe and PayPal were integrated into the workflow.
Stage 6 — Post-Payment Fulfillment
The booking process was extended to include shipment-label access.
Stage 7 — Production
The system was moved toward the production courier website.
The Most Important Technical Lesson
The biggest lesson from this project is that API integration is rarely just about making an HTTP request and displaying the response.
In a real business environment, the API sits inside a larger system:
Customer
↓
WordPress Form
↓
PHP Application Logic
↓
Norsk Global API
↓
Shipping Services / Pricing
↓
Business Pricing Rules
↓
Currency Conversion
↓
Payment Gateway
↓
Shipment Booking
↓
Shipping Label
↓
Customer
Every layer introduces its own requirements.
The API might return a price in one currency.
The business may sell in another.
The supplier price may need a markup.
The customer may need to pay through Stripe or PayPal.
The booking may require customs information.
And after payment, the customer may need a printable label.
A successful integration therefore requires understanding both technical requirements and business requirements.
What Made This Project Different
Several characteristics made this project particularly valuable as a development case study.
1. It involved a real third-party logistics API
The integration was not built around a simple demonstration API. It required dealing with real shipping-service rules and provider support.
2. It required iterative debugging
Several problems could not be solved solely from the original documentation. Request/response analysis and communication with Norsk were essential.
3. It combined multiple systems
The project brought together:
- WordPress
- PHP
- Norsk Global API
- Stripe
- PayPal
- Currency conversion
- Google address suggestions
- Shipping-label functionality
4. The requirements evolved
The project began with an API integration and gradually became a much larger application.
5. The focus moved from code to business workflow
The final objective was not simply:
“Does the API work?”
It was:
“Can a customer successfully obtain a quote, choose a service, pay, book a shipment and obtain the necessary shipping information?”
Project Outcome
The conversation history documents the development of a working courier-booking workflow and its continued refinement toward production.
The client ultimately moved from asking whether the API could be integrated to requesting additional functionality, design improvements, payment integration, pricing logic, currency conversion, shipment labels and deployment.
The client also discussed deploying similar functionality on additional websites, indicating that the underlying integration had value beyond the original implementation.
The project therefore demonstrated the ability to take a third-party logistics API and progressively transform it into a customized WordPress-based courier booking solution.
Key Takeaways
This project demonstrates several principles that are useful for any business considering API integration.
Start with a working proof of concept
Instead of building the entire application immediately, the integration was tested service by service.
Test real API responses
Documentation provides the structure, but real responses reveal the practical problems.
Separate API problems from application problems
A failed API request does not necessarily mean the PHP code is wrong. Service restrictions, account settings, credentials and route rules can all affect results.
Build around the business workflow
The API is only one part of the solution.
Expect requirements to evolve
Once customers and business owners begin testing the system, additional requirements naturally appear.
Build for the complete transaction
For an online courier service, the complete experience includes:
Quote → Select → Book → Pay → Track → Label
not merely:
API → Response
Conclusion
What started on February 8, 2023 as a request to integrate a parcel-delivery quotation API became a multi-stage WordPress/PHP logistics application.
The project required API integration, debugging, third-party coordination, customer-facing forms, shipping logic, payment processing, currency conversion, pricing rules, shipment tracking and label handling.
Most importantly, the project illustrates the difference between connecting an API and building a business workflow around an API.
The technical challenge was not simply sending requests to Norsk Global.
The real challenge was turning those API capabilities into a usable courier-booking experience for customers of Courier.ie.
That progression—from a small API request to a complete business workflow—is what makes this project a valuable example of practical API integration and WordPress/PHP development.
Leave a Reply