HTTP Methods for SaaS Integrations

HTTP Methods for SaaS Integrations

HTTP methods (also called HTTP verbs) are essential to SaaS integrations. But before these methods were used for integrations, they were developed for web browsers. Initially used for displaying web pages, these requests became essential for submitting forms and doing the many other functions necessary for today's media-heavy websites.

In this post, we'll be focusing on HTTP methods as used for SaaS integrations.

History of HTTP methods

The first version of HTTP was extremely simple and only used the GET method. Here's a browser request circa 1991:

GET /webpage.html

And here's the corresponding result:

  This is a webpage.

In 1994, the first full HTTP specification included GET, HEAD, and POST methods. In 1999, the HTTP 1.1 specification added PUT, TRACE, DELETE, OPTIONS, and CONNECT. PATCH made it on the list in 2010.

In addition to these, WebDAV (web distributed authoring and versioning) has defined more HTTP methods. However, these methods focus on remote file editing and manipulation and are not commonly seen with SaaS integrations.

What methods do SaaS integrations use

As noted, we have the following methods as part of the most current HTTP specification:

  • CONNECT: set up a tunnel with the resource
  • DELETE: remove the resource
  • GET: request data from a resource
  • HEAD: request data, but without a response body (just the HTTP headers)
  • OPTIONS: describe communications option for resource
  • PATCH: partially modify a resource
  • POST: create or fully modify a resource
  • PUT: create or fully modify a resource, but idempotently. If you invoke the same PUT request two or more times, the first request will update the resource and additional requests will overwrite the resource with exactly the same data.
  • TRACE: test the path for the resource

As you can see, five of these methods (DELETE, GET, PATCH, POST, and PUT) interact with a resource to support CRUD (create, read, update, delete) functions. Unsurprisingly, those are the HTTP methods commonly used with SaaS integrations to transport data via HTTP. But the type of API an integration uses determines which methods are supported.

What do APIs mean for HTTP methods?

In theory, you could set up an API to accept any HTTP request method (or even to use custom methods that are not a part of the current HTTP specification). In practice, different types of APIs implement HTTP methods differently (but consistently for each type of API). Let's look at some standard types of APIs and see how each one uses HTTP methods.

REST APIs and HTTP methods

A REST (representational state transfer) API uses all five standard HTTP methods: GET, DELETE, PUT, PATCH, and POST. These methods may be used with numerous API endpoints, each endpoint tied to a single resource (data collection or data record). For example, is the endpoint for working with customer records.

Here are a couple examples of what REST requests look like, using GET and POST.

To get a list of customers from our sample REST API, we can use the following:


To create a new customer via our sample REST API, we can use the following:


You'll notice that the method used makes sense with the operation performed. That is, the GET request receives some data, while the POST request sends some data. While sensible relationship between methods and actions is true for REST APIs, it is not true for many other APIs.

RPC APIs and HTTP methods

RPC (remote procedure call) APIs don't make resources available like REST APIs. Instead, requests to RPC APIs call remote procedures, and the remote procedures perform the necessary functions against the underlying data.

As a result, RPC APIs don't need to use the different HTTP methods because the methods don't determine the action performed; that's the literal function of the remote procedure.

RPC APIs usually implement POST for all HTTP requests.

To get a single customer from our sample JSON-RPC API, we can use POST with the following:

  "id": 1,
  "jsonrpc": "2.0",
  "method": "listCustomers",
  "params": ["u6f6igwe3"]

SOAP APIs and HTTP methods

SOAP (simple object access protocol) APIs are the direct descendent of earlier RPC APIs. They, like RPC APIs, focus on calling remote procedures to perform functions rather than working with resources directly (as REST APIs do).

SOAP APIs use a single HTTP method for all requests: POST.

To get a single customer from our sample SOAP API, we can use POST with the following:

<?xml version="1.0"?>
   <SOAP-ENV:Body xmlns:m="">

GraphQL APIs and HTTP methods

GraphQL APIs are quite different in function from REST, SOAP, and RPC APIs. GraphQL APIs also implement HTTP methods differently, supporting both POST and GET.

Like SOAP and RPC APIs, however, GraphQL APIs each have a single endpoint.

To get a single customer (and related user data) from our sample GraphQL API, we can use POST with the following:

query {
  getCustomer(id: "87983") {
    user {

We could also query for a single customer using GET, but we would need to include all of our query parameters in a single string. Because this can make the HTTP request grow long enough to trigger a 414 error (Request URI too Large), most implementations of GraphQL use POST as the standard method for HTTP requests.


HTTP methods are essential for SaaS integrations that connect over HTTP. Different types of APIs implement the methods differently, but each API that accepts HTTP as the transfer protocol must also use at least one HTTP method for HTTP requests.

The methods supported by different API types are as follows:

  • GraphQL API: POST and GET

For more content on HTTP methods and other integration topics, check out our guide to API integrations.

Want to learn more about API integrations?

Want to learn more about API integrations?

Download our API Integrations Guide to see what an API integration is and learn how it works.

Get my Copy

About Prismatic

Prismatic, the world's most versatile embedded iPaaS, helps B2B SaaS teams launch powerful product integrations up to 8x faster. The industry-leading platform provides a comprehensive toolset so teams can build integrations fast, deploy and support them at scale, and embed them in their products so customers can self-serve. It encompasses both low-code and code-native building experiences, pre-built app connectors, deployment and support tooling, and an embedded integration marketplace. From startups to Fortune 100, B2B SaaS companies across a wide range of verticals and many countries rely on Prismatic to power their integrations.