EasyPost is a platform for shippers and marketplaces to integrate with various shipping carriers through an easy-to-use JSON API. We have had to build out integrations with over 100 carriers, decrypting varied frameworks for shipping APIs, converting XML to and from the carriers back to intelligible JSON objects that are easily actionable by our customers. For each of these integrations, there are a number of hurdles we overcame: mapping values and workflows between our framework and the carrier’s, crafting a test suite to verify functionality, and documenting the services supported by the carrier and that we support in the integration. Between Postman’s collections, tests, and documentation functionality, we’ve been able to get ahead of engineering to avoid pitfalls that stop engineering for weeks at a time. The audience will learn how to utilize Postman to get ahead of their engineering team and use Postman's simple HTTP interface to prep API integrations, verify their functionality, and document example calls for the integration. By the end of this talk, you should understand how to optimize your engineering resources and maintenance of information by utilizing Postman’s robust feature set.

2. Getting Ahead of Engineering
September 12th, 2019
Brian Thompson and Peter Durlacher

3. Quick poll

4. What is EasyPost?
- Logistics Technology Company
- Multi-carrier Shipping API
- Address Verification
- Shipment Rating
- Label Generation
- Tracking
- Order Warehousing and
Fulfillment

5. Architecture of EasyPost APIs
User
EasyPost
Carrier API
Carrier
Microservice
Carrier API
Carrier
Microservice
Carrier API
Carrier
Microservice

6. Architecture of EasyPost APIs
Carrier API
User EasyPost
Carrier Microservice

7. What do we do?
Solutions
Engineering
Sales
Support
Product
Management
Engineering

8. What do we mean?
Getting Ahead of Engineering

9. Lesson #1 (Product)
Lesson #2 (Sales)
Lesson #3 (Engineering)
Lesson #4 (Solutions)
Lesson #5 (Support)
Lessons

10. Problem:
Small hiccups in carrier
integrations force engineers to
pause mid-project
Examples:
- Carrier credentials have the
wrong set of permissions
- Ambiguous carrier terms for
services and features
Lesson #1 (Product)

11. Lesson #1 (Product)

12. Nothing should stop an engineer!
- Configurable variables to clearly
outline what an API’s mappings should
be
- Verified success of calls means
engineers can hit the ground running
- Tests let you string requests
-
Lesson #1 (Product)

13. Lesson #2 (Sales)
Problem:
Non-technical team members need to be trained
Examples:
- Members are unfamiliar with HTTP requests
- It is unclear where the API fits in a potential client’s tech/logistics stack

14. Everyone can be an expert!
- Collections that walk you
through basic API flows
- Descriptions that elaborate
on use case and reason for
API calls
Lesson #2 (Sales)

15. Everyone can be an expert!
- Collections that walk you
through basic API flows
- Descriptions that elaborate
on use case and reason for
API calls
Lesson #2 (Sales)

16. Lesson #3 (Engineering)
Problem:
Internal tests do not check all corner cases.
Examples:
- Deploying one fix breaks another feature
- One engineer identifies a corner case, but doesn’t share it to a central
source

17. Lesson #3 (Engineering)
Edge cases are just tests you haven’t made yet!
- A shared collection of requests that can verify
that a carrier integration is “full-featured”
- Tests allow you to search for specific values in the
response that confirm expected behavior (not
just “no error”)

18. Lesson #3 (Engineering)
Edge cases are just tests you haven’t made yet!
- A shared collection of requests that can verify
that a carrier integration is “full-featured”
- Tests allow you to search for specific values in the
response that confirm expected behavior (not
just “no error”)

19. Lesson #4 (Solutions)
Problem:
Clients cannot always visualize a fully-built solution - sometimes you need to
take it a step beyond explanation.
Examples:
- How do you implement the logic to optimize for speed and cost?
- How do you optimize between more than one warehouse locations with
the same inventory?

20. Lesson #4 (Solutions)
Don’t just share the docs, do
demos!
- Using Postman tests, you
can actually implement logic
that will help a client
visualize what your API can
do

21. Lesson #5 (Support)
Problem:
Before you can solve a problem, you need to be able to replicate it.
Examples:
- Why is EasyPost not returning a particular DHL Express rate?
- Does DHL Express support that service given these conditions?

22. Be the support you want to see
in the world!
- By replicating the problem,
you can start tweaking
requests to find the solution
- Finding the answer will
always be a better customer
experience
Lesson #5 (Support)

23. Conclusion
Tie it allllll together!
Postman can:
- Design a product
- Teach account executives
- Test an API
- Present solutions to clients
- Troubleshoot your product
- Aaaand bake a perfect
souffle!
Other Postman things we WANT
to implement
- Mock servers
- Documentation / Examples
- Even more tests