curl -b / -c: Send and Save Cookies
Some endpoints use session cookies, and -c plus -b carry the session between calls.
When an API authenticates with a session cookie rather than a token, you save the cookie on login and replay it on later calls.
What it does
-b / --cookie sends cookies: either a name=value string or a file to read from. -c / --cookie-jar <file> writes the cookies the server set to a file when the transfer ends. Together they implement a session: -c on the login request saves the session cookie, and -b on later requests sends it back. Using the same file for -b and -c carries state across a sequence of calls.
Common usage
# log in and save the session cookie
curl -c jar.txt -d 'user=ci&pass=secret' https://api.example.com/login
# reuse it on subsequent calls
curl -b jar.txt https://api.example.com/protected
# send a cookie inline
curl -b 'session=abc123' https://api.example.com/xFlags
| Flag | What it does |
|---|---|
| -b 'k=v' | Send a cookie as a literal name=value |
| -b <file> | Read cookies to send from a file |
| -c <file> | Save received cookies to a jar file |
| -b <file> -c <file> | Same file: persist a session across calls |
| -j / --junk-session-cookies | Ignore session cookies when loading |
In CI
For a multi-step flow, use one cookie jar across the calls so the session persists. Treat the jar as a secret artifact, since it can contain a live session; write it to a temp path and delete it at the end of the job rather than caching it between runs.
Common errors in CI
A 401 on the second call usually means -c did not save the cookie (login failed, or the server set it on a redirect you did not follow). Add -L so cookies set during redirects are captured, and confirm the login response actually returned a Set-Cookie.