Introduction
Some forward deployed engineers spend a surprisingly large amount of their time working with APIs. A customer may already have a CRM, a ticketing system and a few internal databases. An FDE’s AI solution needs to integrate with all of them. The right API tools can turn an FDE’s task from a chore into a routine. This guide will discuss the tools FDEs tend to use, and which ones are suited for specific tasks.
Why API Tools Are Important for an FDE
An FDE rarely works inside of a single code repository. Instead, they work across disparate systems, some designed years ago by other teams. Some have good documentation while others have none at all.
As such, FDEs typically need tools that allow them to explore and test endpoints quickly. FDEs also need tools that make it easy to communicate what they are doing to a customer. The ability to show a customer a request and response in a visual format can help establish trust.
Postman: Explore and Test APIs
The first tool many FDEs will try is Postman. It lets them send requests and check out responses. All of this can be stored in a collection for future reference with no code needed.
Postman is also a collaboration tool. A request and response collection can be shared with a customer’s own developers. This can reduce confusion on either side. The tool has options for different authentication types such as API keys or OAuth. Postman can also be used for testing and mocking servers. This makes it valuable for an FDE throughout their engagement.
Insomnia and Bruno: Alternatives
Some FDEs may find that a less feature-heavy client is better for their needs. Insomnia has a cleaner interface and good features, but it lacks some advanced options. Bruno stores collections as files that can be placed under version control with the rest of an FDE’s code.
Neither tool is better than Postman across the board, but both have their advantages. An FDE should try different tools until they find the ones they prefer.
cURL and HTTPie: Quick Checks from the Terminal
There are times when an FDE needs to make a single request to an endpoint. This is typically done with a command line utility such as cURL. These tools are typically available anywhere an FDE may need them, even behind a customer’s firewall.
HTTPie has a nicer interface and colored output, but it is still primarily the same concepts as cURL. Either tool can be used for a quick request that doesn’t warrant setting up a Postman collection. An FDE may find themselves using these tools when a graphical utility is unavailable.
FastAPI: Building Services
It is common for a client to need some middlemen between their services and an FDE’s AI solution. A popular framework for building these services is FastAPI. It is lightweight and uses Python, a language common in the AI space.
Using FastAPI reduces the amount of time spent on boilerplate code. It can automatically generate documentation for each endpoint as it is created. This lets an FDE or the client quickly experiment with a service without additional tools. The framework can also validate incoming data, reducing potential issues during training or inference.
Swagger and OpenAPI: Documentation
Proper documentation for an API is important for its adoption. Swagger provides a way to define an API in an OpenAPI spec, then outputs documentation based on it. For an FDE this means taking advantage of a spec provided by a client or generating one for a service they built.
n8n: Automating Workflows
Not every customer-facing automation needs to be a custom-coded application. There are tools such as Zapier, Make or n8n that allow creating connections between services through visual interfaces. These services can be used to set up webhooks or automate repetitive tasks without writing a single line of code.
n8n is notable for being self-hosted, or available in a private cloud version. This is important for some customers who will not allow data to pass through third-party services. Like any tools, these services have their place. While they may be quicker to set up, a custom-coded solution may be necessary for performance-critical or unique operations.
API Gateways and Authentication Tools
As an FDE’s solution grows, they will likely need to consider security. API gateways can act as a central point for handling API-related tasks. Tools such as Kong, AWS API Gateway or Azure API Management can handle rate-limiting, authentication and other tasks.
Authentication itself has a set of tools. An FDE should be familiar with the basics of OAuth 2.0 and JSON Web Tokens. There are also services such as Auth0 or Keycloak that can handle the mechanics of authentication for an FDE without implementing it themselves.
Monitoring and Debugging Tools
After an FDE’s solution is deployed, it needs to be monitored. Tools such as Datadog, Sentry or Grafana can monitor an API for errors, performance issues and traffic patterns. This can greatly reduce the amount of time spent on support requests by catching minor issues before they turn into emergencies.
In an AI context, additional tools are needed. An FDE should track the number of tokens used for each request, and the cost associated with it. Tools such as Langfuse or Helicone can do that while also providing information about the state of a request.
Logging is another important part of debugging. An FDE should make sure their service can provide enough information to diagnose an issue, but that any sensitive information is removed. The right logging strategy reduces the time spent on debugging by an order of magnitude.
How to Choose the Right Tools
An FDE does not need to use every tool discussed here. In fact, many FDEs would only use a handful of tools throughout their career. A good starting point is to pick one tool for general API testing and exploring. Something like Postman is a good fit for this role.
An FDE will also need a tool for making quick requests from the terminal. This can be cURL, or a more modern tool such as HTTPie. Finally, a framework for building services and API endpoints is necessary. Something like FastAPI serves this purpose well. Tools for documenting APIs and monitoring them are also important, but an FDE should learn them as needed.
Finally, an FDE should pick tools that are best suited for the customers they work with. A tool may be great, but if it is unavailable in a customer’s internal network, it is not useful to the FDE. The choice of tooling is a matter of personal preference and experience. There are no right or wrong choices to be made here.
Final Thoughts
The best API tools for an FDE have one thing in common – they help them work faster. Postman and cURL are good at letting an FDE explore and test an API. Tools such as FastAPI or Swagger help an FDE build and document their own APIs. A good logging and monitoring strategy will reduce the amount of time spent on emergencies after an FDE’s work is deployed.
The tools themselves will change over time, but the approach will remain the same. It is possible to practice these concepts outside of a real-world engagement with a customer. Doing this will be helpful to an FDE regardless of which tools they choose to use.