First business use case - Gliding Eagle

[jduan00]

Gliding Eagle is using EG1 to standardize tracking and internal logistics automation (and notifications).

@psamiot is the first developer to use EG1 api and data (hosted on eagl.io).

[psamiot]

In Gliding Eagle, shipment tracking has always been a core feature. Initially, we integrated directly with multiple carriers like FedEx and SF Express. While this worked, it was really complex for a small development team — multiple API keys, different response formats, hard to stay up to date with API changes.

So, my experience with Eagle1 API as a developer?

1. One API Key Instead of Many

One less thing to worry about. Save time from managing accounts, credentials to rotate, tokens to refresh. Just focus on development.

With Eagle1, we only needed a single API key to access multiple carriers. This significantly reduced setup time and simplified our configuration.

2. A Clean and Simple Data Structure

Carrier APIs are designed to handle every possible logistics scenario. While powerful, they often return deeply nested and complex data structures. Not needed in our use case.

Eagle1 keeps it flat and focused. Exactly what we need. An array of events answering our main questions: what, whom, when, where.

{
  "status": 3100,
  "what": "Received by Carrier",
  "whom": "FedEx",
  "when": "2024-11-11T14:16:48-06:00",
  "where": "SAN FRANCISCO, CA"
}

This made it much easier for us to:

• Parse responses
• Store data
• Predict data anomalies

No more digging through layers of optional fields just to find a tracking update.

3. Faster Response Times

One noticeable improvement was response speed.

Direct carrier APIs sometimes introduced latency due to heavier processing and more complex payloads. With Eagle1, responses were consistently faster, which helped us:

• Improve user experience
• Reduce backend waiting time
• Streamline our tracking jobs

4. One Unified Model Across Carriers

Before, each carrier had its own:

• Status codes
• Naming conventions
• Event structures

We had to build and maintain mapping logic for each one.

Eagle1 solves this by providing a unified data structure, regardless of the carrier. This means:

• One parsing logic
• One internal data model
• Less room for bugs and inconsistencies

---

From a company perspective, this shift reduced operational complexity and dependency on multiple external integrations. Onboarding new carriers is no longer a project on its own, which means faster expansion and lower maintenance costs. It also improves reliability, since we rely on a single, consistent interface instead of multiple fragile integrations.

From a developer perspective, the benefits are immediate. There’s less boilerplate, fewer edge cases to handle, and significantly less time spent reading documentation or debugging mismatched data structures. The unified model allows us to focus on building features instead of maintaining integrations, which ultimately leads to faster development cycles and cleaner code.

[jduan00]

Thanks for sharing! That’s precisely why we designed Eagle1 to simplify the process of tracking shipments for developers.

[samshdn]

I have carefully read through the entire content above.
You have accurately captured all the key aspects of this project. To summarize: we are committed to providing developers with a concise, efficient, and reliable API to track data from various logistics service providers.

[jduan00]

@psamiot
Can you quantify the time and effort saved with Eagle1 compared to before? Also, what’s the typical time required to pull data from FedEx versus Eagle1?

[psamiotis]

@jduan00 @samshdn

Latest results for our use case, after the v0.3 Major Release:

FedEx native API

• Batch limit: 20 tracking numbers per call
• Response time: ~3-5s per call
• To track 100 numbers: 5 sequential calls → ~15-25s
• To track 1,000 numbers: 50 sequential calls → ~150-250s (2.5-4+ min)

Eagle1 (current, no batch support yet — concurrency only)

• 100 tracked: 0.59s (0 failed)
• 1,000 tracked: 0.66s (0 failed)

The fact that 1,000 lookups take barely longer than 100 tells us the bottleneck isn't per-item processing — it's network handshake overhead, and concurrency is absorbing that almost entirely.

Net time savings: for a 1,000-number run, we're looking at roughly 200s → 0.66s, on the order of 300x faster than sequential FedEx batch calls. Even at 100 numbers it's a 25-40x improvement.

Next step: once batch tracking is supported, we should be able to push well past FedEx's 20-per-call ceiling and cut total round-trips even further — batch + concurrency combined rather than either alone.

[jduan00]

Thanks @psamiotis for sharing. This aligns with our prediction. Per request is about 0.5 ms using SQLite db in the API backend infr.

[jduan00]

@psamiotis Could you please share the code snippet you’re using to access Eagle1 with concurrent API access? This might help other users with a good working example!