How to specify the HTTP method in cURL

Selecting the correct HTTP method in cURL keeps API tests, webhooks, and automation aligned with the endpoint contract. A request that hits the right URL with the wrong verb can return 405 Method Not Allowed, bypass cache expectations, or mutate data when a safe read was intended.

In a plain URL transfer, cURL defaults to GET. Adding body options such as --data changes the underlying request flow, while --request changes the method token that cURL sends on the wire for verbs such as PUT, PATCH, DELETE, or OPTIONS. Purpose-built options still matter: --head makes a real header-only HEAD request, while --request HEAD changes only the verb string.

Custom methods often pass through gateways, auth layers, and redirects differently than a simple GET. Validate non-default verbs against a safe echo endpoint before pointing them at production APIs, and inspect the sent request line when the server behavior does not match the method that was intended.

The examples below use masked maintenance-window endpoints and sample identifiers so the method flow stays realistic without publishing a live API surface.

1. Send a URL-only request first to confirm cURL's default method behavior.

   $ curl --silent --show-error 'https://ops-api.example.net/v1/maintenance-windows?state=scheduled'
   {
     "args": {
       "state": "scheduled"
     },
     "method": "GET",
     "url": "https://ops-api.example.net/v1/maintenance-windows?state=scheduled"
   }

   A plain HTTP or HTTPS URL uses GET unless another option changes the request flow.

2. Set a non-default method with --request when the endpoint expects a different verb for the same URL.

   $ curl --silent --show-error \
     --request PUT \
     --data 'status=active' \
     https://ops-api.example.net/v1/maintenance-windows/mw-48217
   {
     "form": {
       "status": "active"
     },
     "headers": {
       "Content-Type": "application/x-www-form-urlencoded"
     },
     "method": "PUT",
     "url": "https://ops-api.example.net/v1/maintenance-windows/mw-48217"
   }

   --request changes the HTTP verb only; keep choosing --data, --json, or --data-binary based on the body format the server expects.

3. Send partial updates with PATCH when only selected fields should change.

   $ curl --silent --show-error \
     --request PATCH \
     --json '{"status":"paused"}' \
     https://ops-api.example.net/v1/maintenance-windows/mw-48217
   {
     "headers": {
       "Accept": "application/json",
       "Content-Type": "application/json"
     },
     "json": {
       "status": "paused"
     },
     "method": "PATCH",
     "url": "https://ops-api.example.net/v1/maintenance-windows/mw-48217"
   }

   If --json is unavailable on an older curl build, send the same payload with --header "Content-Type: application/json" plus --data.

4. Use DELETE when the API expects the resource URI plus a removal verb.

   $ curl --silent --show-error \
     --request DELETE \
     https://ops-api.example.net/v1/maintenance-windows/mw-48217
   {
     "method": "DELETE",
     "url": "https://ops-api.example.net/v1/maintenance-windows/mw-48217"
   }

   Run DELETE, PUT, and PATCH first against a safe test endpoint or disposable resource so a mistyped path does not change live data.

5. Use --head for header-only checks instead of --request HEAD.

   $ curl --silent --show-error --head https://ops-api.example.net/v1/maintenance-windows/mw-48217
   HTTP/2 200
   content-type: application/json
   content-length: 428
   etag: "mw-48217-v12"
   cache-control: no-store
   server: envoy

   Use --head or -I for real header-only checks. Official curl documentation notes that --request HEAD changes only the method word, not the transfer mode.

6. Query server capabilities with OPTIONS before using uncommon or potentially blocked verbs.

   $ curl --silent --show-error --include --request OPTIONS https://ops-api.example.net/v1/maintenance-windows/mw-48217
   HTTP/2 204
   content-length: 0
   allow: GET, HEAD, PUT, PATCH, DELETE, OPTIONS
   access-control-allow-methods: GET, PUT, PATCH, DELETE, OPTIONS
   server: envoy

   The Allow response header is a quick way to confirm whether the next method is expected to succeed or fail with 405 Method Not Allowed.

7. Inspect the request line before reusing a mutating command in scripts or pipelines.

   $ curl --output /dev/null --verbose \
     --request DELETE \
     https://ops-api.example.net/v1/maintenance-windows/mw-48217
   * Host ops-api.example.net:443 was resolved.
   * Connected to ops-api.example.net (192.0.2.24) port 443
   * using HTTP/2
   > DELETE /v1/maintenance-windows/mw-48217 HTTP/2
   > Host: ops-api.example.net
   > User-Agent: curl/8.x
   > Accept: */*
   >
   < HTTP/2 204
   < server: envoy

   The line beginning with > confirms the exact method and path sent on the wire, which is the fastest check when a proxy, script wrapper, or redirect changes request behavior.