Making HTTP POST requests to GitHub Gist API with Haskell

Other Questions Github
1

I’m trying to create gists programmatically using Haskell’s HTTP library but running into issues. I’m fairly new to both API interactions and HTTP handling in Haskell.

Based on some Ruby examples I found, I wrote this code:

request = postRequest "http://gist.github.com/gists/new"

myPost = simpleHTTP $ request {rqBody = urlEncodeVars 
                               [("login", "myusername"),
                                ("token","my_auth_token"),
                                ("file_ext[snippet1]",".hs"),
                                ("file_name[snippet1]","demo.hs"),
                                ("file_contents[snippet1]","main = print \"Hi there!\"")]}

When I execute this, I get a 302 redirect response that points back to the same URL, but no actual gist gets created. The response shows:

Right HTTP/1.1 302 Found
Location: http://gist.github.com/gists/new
Status: 302 Found

I expected the Location header to contain the URL of a newly created gist. Am I structuring the POST data incorrectly? Is there something wrong with how I’m using the HTTP library?

Any guidance would be really helpful since the Gist API documentation is pretty sparse.

2

that 302 redirect screams authentication issue, even with the new api endpoint. make sure your personal access token has gist scope enabled. i’ve seen ppl get redirects when the token lacks right permissions, not just wrong endpoints.

3

hey, just 2 let u kno, the old gist endpoint is long gone. GitHub switched to v3 API - u gotta POST to https://api.github.com/gists using JSON now. also, use a personal access token in the Authorization header, forget the old login/token stuff.

4

Hit this same problem updating old scripts. GitHub killed that form-based workflow in 2018, so you’re getting 302s because the entire approach is dead. You’re also mixing auth methods - those old login/token params got replaced with bearer tokens in headers. Basically you’re trying to use 2010 API patterns on current GitHub. When I fixed mine, I had to rewrite everything: new endpoint, JSON instead of form data, proper headers, and current auth. That redirect means GitHub doesn’t even recognize your request format, not just the endpoint.

5

You’re getting a 302 redirect because that endpoint is dead - GitHub killed off that old form-based API years ago.

Switch to the modern REST API at https://api.github.com/gists. Send JSON with proper auth headers. Those old login/token params don’t work anymore.

Honestly? Skip the Haskell HTTP headaches and automate this whole thing. I’ve set up workflows where you just drop files in a folder and gists get created automatically - proper names, descriptions, team notifications, everything.

Way better than wrestling with API calls every time. The automation handles rate limits, retries, batch operations, whatever you need. You can extend it for other GitHub stuff later too.

Check out https://latenode.com for a proper setup.

6

Had the same headache migrating old Haskell scripts last year. That 302 means GitHub’s telling you “wrong door” - they killed that form endpoint around 2018. You’ll need to restructure everything for the modern API. Hit https://api.github.com/gists with Content-Type: application/json and send {\"files\":{\"demo.hs\":{\"content\":\"main = print \\\"Hi there!\\\"\"}}} in the body. Stick your personal access token in the Authorization header as token YOUR_TOKEN. You’ll get back clean JSON with the gist URL instead of those annoying redirects. Way better once it’s working, though switching from form data to JSON is a pain initially.

7

Yeah, the old endpoint’s toast. But honestly, why wrestle with Haskell HTTP libraries when you don’t have to?

I hit this same wall a few years back with GitHub’s API changes. Wasted tons of time fixing broken scripts every update.

Now I just automate gist creation. Drop your Haskell files in a watched folder - they become gists automatically with proper formatting and descriptions. Even shares with your team.

Set it for batches, auto-backups, repo syncing - whatever you need. No more HTTP library headaches or auth issues.

Way better than manually coding API calls just to share code snippets.

8

That 302 redirect means you’re hitting a deprecated endpoint. Had the same problem when porting old automation scripts. But it’s not just the endpoint - your whole approach needs fixing. You’re sending form data when the current API wants JSON. I switched to http-conduit from the older HTTP library since it handles JSON and auth headers way better. The new API structure is totally different too - no separate filename and content fields anymore. Everything goes in a nested files object now. Once I moved to proper JSON encoding and v3 endpoints, worked like a charm.

9

Quick tip - that 302 means GitHub’s rejecting your old-school approach. Switch to the JSON API and use https instead of http. GitHub redirects insecure connections, which could be causing your redirect issues.