Blog

In software development, application programming interfaces (APIs) are an absolute necessity. APIs play a crucial role in enabling various systems to communicate and share data with one another. These versatile tools make it possible for developers to incorporate ready-made code into their applications, saving them the time and effort of creating complex features from scratch. Just as peanut butter pairs perfectly with chocolate, and a baseball game isn’t complete without sunshine, APIs are an integral part of a developer’s toolkit.

When it comes to working with APIs, there’s one tool that stands out above the rest: Postman. Loved by over 15 million developers and half a million companies worldwide, Postman has emerged as a key tool for programmers who need to test APIs, streamline their workflows, and save time.

Postman is more than just an API testing application. It’s an all-in-one platform that supports every stage of the API lifecycle, from design and development to testing, documentation, and monitoring. With its user-friendly interface and extensive API collections, Postman has simplified the often-complex task of working with APIs.

Imagine you’re experimenting with a new API. You would likely need to set up the necessary request details, create an account, and provide account credentials before making the API call. With Postman’s API collections, all these details are readily available, cutting down your setup time and letting you ‘plug and play’ with ease.

As a testament to its effectiveness, the development team at DataMotion frequently utilizes Postman in their work, appreciating the many ways this tool enhances their productivity and efficiency.

Postman is more than just an API testing application. It’s an all-in-one platform that supports every stage of the API lifecycle, from design and development to testing, documentation, and monitoring. With its user-friendly interface and extensive API collections, Postman has simplified the often-complex task of working with APIs.

After extensive use of Postman and thorough research, the development team at DataMotion has pulled together numerous tips and tricks to make the most of this powerful tool. These tips will save you time, streamline your API testing process, and help you become a Postman guru.

Manually updating headers and parameters for each request can be time-consuming and repetitive. The ‘Bulk Edit’ feature in Postman is a lifesaver here. You can access this feature in the Header and Params sections, allowing you to see the list of headers or params in text rather than in a table format. This then allows you to copy the text and paste it into your new request. In the same section of your new request, select ‘Bulk Edit’ again and paste the text within. From here you can select ‘Key Values’ which has replaced the bulk edit option to see all your headers or params in the table format. This way, you can swiftly update your requests without having to modify each one individually.

Another handy feature in Postman is its support for variables. You can set up variables within a folder or collection for data that is used repeatedly across multiple requests. For example, in DataMotion’s API collections, we have a header for a session key in most of our requests. When the session key updates, you can instead create a variable and update the session key variable’s value. You can then use {{variable}} to reference the variable in your requests. This simplifies updating the session key; you just update the variable value once, and it applies to all references across your requests.

As a developer, quality assurance (QA) testing is an inevitable part of your role. Postman has a convenient way of allowing you to test multiple requests at once with the same script. To do this, select the folder or collection containing the requests you want to test, then navigate to the ‘Test’ tab and add your test code. You can then run the entire collection, executing multiple tests at the same time.

There might be times when you want to run a request without certain headers or parameters. Rather than deleting them and then having to add them back in later, Postman lets you disable or enable headers or parameters with a simple click. Deselect the checkbox next to each header or parameter you want to disable. This allows you to run the request with only the enabled headers or parameters included.

A great tip I recently learned utilizes the Postman console to update environment variables using data from a JSON response. You can write a script that parses the JSON response returned after making a request, then update an environment variable with this response data – all within Postman.

This trick is particularly useful when getting session keys. Within the DataMotion Postman collection, several requests require a session key. To streamline the testing process, I created a ‘SessionKey’ variable that allows me to easily update each instance at once. Then I add the following code to my console, which captures the updated session key from DataMotion’s ‘Get Sessionkey’ API call and automatically populates the ‘SessionKey’ variable with the response.

var data = JSON.parse(responseBody);

postman.setEnvironmentVariable(“SessionKey”, data.SessionKey);

This ensures that the ‘SessionKey’ variable in the majority of my requests consistently reflects the most current session key retrieved through the ‘GetSessionkey’ API call.

The session key variable is scattered across the DataMotion collection. If the variable name needed to changed or be updated, it would be a long and menial task to complete. However, this work can be replaced with Postman’s find and replace feature.

To rename a variable, such as the session key variable or an attribute name, navigate to the bottom right of your Postman workspace to find the “Find and Replace” button. Select this button and type in the phrase or regex pattern you would like to identify. From here, select specific instances of this phrase to update or select all. Then enter the new phrase you would like to replace these instances with under the “Replace With” section and click “Replace.”

Postman is not just an API testing tool; it’s also great for converting your API calls into code. After configuring your Postman request, simply select the code icon on the right panel of your workspace, select a programming language, and copy the generated code snippet of your request.

You can then seamlessly integrate this snippet into your projects for a streamlined development process.

You can create API documentation for your Postman collections using the documentation icon in the right panel of the Postman workspace.

Once you have selected the documentation icon, you will see the documentation for your request, including details on the endpoint, parameters, headers and body values. You can also select the ‘View the complete documentation’ button at the bottom of this view to get documentation on your entire collection. From here, you can select publish in the top right corner to publish this information, directly from Postman.

While Postman is a powerful ally for any API-related work, its functionality is especially evident when used with the secure message center API. Developed by DataMotion, the secure message center API enables secure messaging, email, and document exchange integration into self-service portals like online banking, insurance member services, wealth management portals, and more.

These self-service portals have become the primary interfaces for customers to manage their accounts, conduct transactions, find healthcare specialists, or check insurance claim statuses. However, these portals occasionally fall short of providing secure and compliant communication channels. This is where the secure message center API, built with data privacy and governance regulations like GLBA and HIPAA in mind, comes into play. By integrating the secure message center API into these portals, businesses can quickly establish a robust, secure, and compliant communication resource.

Postman’s ability to test, validate, and demonstrate the functionalities of the secure message center API proves invaluable in these integrations, making it easier for developers to understand, work with, and leverage the API to its full potential.

To help you navigate the complexities of secure messaging and API testing, DataMotion has prepared a series of demo videos showcasing the use of Postman with the secure message center API. These videos serve as a step-by-step guide, walking you through the API’s functionality and demonstrating how Postman can be utilized to facilitate API testing. Not a fan of Postman, but are looking for something different to test APIs? Check out our recent blog post and video demonstration that leverages the Insomnia REST Client for API testing.

Here’s one of our software developers demonstrating our ‘send message’ API. If you’d like to follow along, you can view our Postman Collection on GitHub and try out our APIs in our self-service portal.

This video offers a comprehensive demonstration of folder management with the secure message center API. It covers the essential steps of listing, creating, and deleting folders for efficient organization.

If you are developing a self-service portal for a financial services or insurance company – we hope this taste of secure message center programmability clarifies what you can build with our APIs. Of course, there is a lot more functionality – and all of the secure message center APIs are well documented with sample code and SDKs.

APIs have revolutionized the way developers work, and Postman is one of our favorite tools leading the charge in making API testing more accessible, efficient, and effective. As we continue to explore and discover new facets of this and other powerful tools, we’ll continue to share our knowledge and tips with the developer community. For more insights into the world of Postman, similar tools like Insomnia, and API testing in general, follow us on LinkedIn, Facebook, and Twitter and subscribe to our monthly newsletter. We post new tips and tricks every Tuesday, providing fresh content to help you master these incredible tools. To put your Postman learning into practice, download our Postman collections on GitHub.

Feel free to contact us for any questions or to discuss your project ideas, and don’t hesitate to book time for a conversation or technology demonstration!

Updated November 9, 2023

It’s a common analogy: the decision between building or buying a software application is comparable to choosing whether to build or buy a house. The pros and cons for both are similar. Building it yourself often leads to something made specifically for your needs and could save you money. However, it also can take much longer than predicted and has a substantial risk of unexpected expenses. While choosing to buy can be the simpler and faster decision, you may not receive that “made just for you” feeling you were hoping for. Many of our customers struggled with this dilemma before choosing to use a third-party vendor. Why is this? We’ll highlight five things to consider before developing software in-house and why it may be better to let someone else do the heavy lifting.

Before getting started, we want to emphasize that building software in-house is not always a bad decision. If your desired solution is expected to be core to your business and your team has the resources to build it themselves, then building it in-house can be the better option. Not only will your solution have the features you need, but you’ll also have greater control over it in the long run. On the contrary, if your solution is not expected to handle core business processes and your team has other critical priorities, we encourage you to keep reading.

Now that we’ve gotten that out of the way, let’s get started. Here are five things to consider before building software in-house.

1. It’s a massive time commitment. As we alluded to earlier, building a new software solution or application from scratch can be an extremely long, drawn-out process. In fact, the time it takes to develop the front and back-end infrastructure for a standard web application is 4.5 months. If your project includes complex features, such as secure messaging, assume it will take longer. And when you think you’re done, you’re not. Work isn’t complete once you go live. As the software developer, you will be responsible for monitoring, updating, and supporting your application even after it’s launched.

2. It’s incredibly expensive. When you build software in-house, it’s common to assume that you’re saving money. While that may be true, it’s not always the case. To put the costs into perspective, let’s crunch some numbers.

For simplicity, we’re assuming we have a one-person team, a front-end developer. We’re also assuming they’ll complete the project in 4.5 months while working 40 hours per week.

That works out to 720 hours for one employee to work on a single application. Odds are, you’ll have a team of developers working together, so make sure to multiply that number by the number of people on your team.

Since we’re talking in terms of money here, let’s convert that to how much you will spend during that time frame, using $57 as the average pay per hour for a front-end developer in the United States.

$41,040. That’s the minimum you’ll spend to build a standard web application. Now, we’ll admit that math was not perfect. You’ll likely have a larger team, consisting of employees in various roles, all getting paid different amounts.

Not to mention – all that time and money that went towards building your application could have been spent focusing on other priorities, so there’s an opportunity cost to consider.

3. It’s (probably) already been built. Unless your requirements are highly specific and unique, there’s an excellent chance someone has already built all, or at least part of, what you’re searching for. A third-party vendor has already put an extensive amount of time and work into testing and perfecting their solution to ensure it works exactly as expected. Thus, they will know the ins and outs of their product, how it was built, what it can and cannot integrate with, the potential to customize it, and solutions to common problems. In short, these folks have years of experience and know what they’re doing.

Word of warning: not every third-party vendor is built equal. While many have taken the necessary steps to protect their system’s security and meet the needs of their customers, it’s important to do your due diligence when choosing to outsource all, or parts of, your project. Here are 14 points to consider when vetting a third-party vendor, particularly when choosing an API company.

4. You will be your own support team. As mentioned earlier, building software in-house means providing support for your software throughout its lifespan. This requires a significant, ongoing time commitment from your team. It also involves a constant effort to maintain the skills and knowledge to properly respond to requests. This means continuous training for your current team, and any future team members.

5. Other products have been polished and perfected. Remember when we mentioned earlier that an application with your requirements has likely already been built? This is a critical topic, so we’re going to reference that again in this last point. Many API and SaaS companies have been around for a while and have already spent years testing, modifying, and updating their services. Often, this results in a fine-tuned product specifically designed to meet customer demands.

This experience factor is also important to consider if your desired solution must comply with industry and privacy regulations. To satisfy compliance requirements, specific steps must be taken, and certain criteria met both within the services offered and the organization who provides the service. Many third-party vendors have already taken the extensive time needed to fulfill these requirements so their customers can focus their resources elsewhere.

Building software in-house may sound like a promising idea when you’re considering a project. However, it is critical to assess the pros and cons of building it yourself, lest you fall into a never-ending development cycle. And if your project involves any type of secure messaging system, additional time must be taken to meet regulatory compliance requirements.

To close out this blog post, we’d like to provide you with five preliminary questions to ask yourself when choosing to build or buy software:

1. Is my desired solution core to my business processes?
2. How much time and money should I devote to my project?
3. Do integrations for any of my solution’s preferred features exist?
4. Do I have the resources to update, maintain, and provide support for my solution throughout its lifespan?
5. If my solution deals with any kind of sensitive information, what are the relevant regulations with which it must comply?

DataMotion offers a variety of API and pre-built solutions for organizations seeking to add an easy-to-use and secure messaging system to their communications toolkit. We also offer several pricing plans for our pre-built services and tiered pricing for our transactional APIs. To get an estimate on how much you’ll spend using our secure message delivery API, you can use the calculator on our pricing page.

• Choosing an API Company: 14 Points for Due Diligence
• DataMotion: A Zero Trust Model You Can Trust
• SaaS vs. PaaS: How to Choose What Type of Secure Exchange Solution is Right for You

• How Long Does It Take to Develop a Web App: Answers to All Questions
• Building Software In-house: Is It A Good Idea? (Build vs Buy)
• Hourly Pay for a Front-End Developer (salary.com)
• 7 Reasons In-House Software Fails
• 5 Reasons Why Building Your Own Software Solution is Not a Good Idea
• What to Expect When You’re Developing Software in House
• Ask Yourself These Questions Before Developing Software In-House