Using the GraphQL API

I’ve succesfully used the REST API for years, now I’m trying to get started using the GraphQL api, and to do that I thought it would be a good idea to read:

The GraphiQL interface works nicely, but from the command line there are problems.

I’ve generated a new personal access token, and with that a query to the REST API like:

curl --header "PRIVATE-TOKEN: <token>" --header 'Content-Type: application/json' --header 'Accept: application/json' --request GET 'https://<instance_url>/api/v4/users'

works nicely, but if I try something like the example shown on that page:

curl "https://<instance_url>/api/graphql" --header "Authorization: Bearer <token>" --header "Content-Type: application/json" --request POST --data "{\"query\": \"query {currentUser {name}}\"}"

doesn’t return anything. If I add the -i option to curl, I can see that I get a status of 200 back, and in /var/log/gitlab/gitlab-rails/production.log on the server I can see

Started POST "/api/graphql" for <my ip> at 2023-03-22 15:39:36 +0000
Processing by GraphqlController#execute as */*
  Parameters: {"query"=>"query {currentUser {name}}", "graphql"=>{"query"=>"query {currentUser {name}}"}}
Can't verify CSRF token authenticity.
Completed 200 OK in 51ms (Views: 0.2ms | ActiveRecord: 8.1ms | Elasticsearch: 0.0ms | Allocations: 11004)

(the various values in the last line differ a little between attempts). I get the same lines in there if I change the token in the request (to something that is not correct), so I’m guessing it doesn’t actually verify that.

(The instance is no longer in production, so the logs are quite silent, so I am fairly sure those lines are actually caused by my testing)

What am I doing wrong?

The query works fine for me (replacing real values for “instance_url” and “token”, of course). FWIW, my gitlab version is 15.9.2.

That said, judging by this forum and by things missing in the GraphQL API (no way to create new project or group?), I have the hunch that marketing went ahead of implementation here. But I might be wrong, of course.

(edited because this funny thing eats my angle brackets and I can’t get bothered to figure out yet another funny markup thingy right now)

As it was getting frustrating not getting anywhere, I left this a few days ago, hoping I would be able to see what I was doing wrong when I came back to it, so it’s not completely fresh in my mind.

As the instance is no longer in production, I also haven’t bothered to upgrade it lately, so it’s still on 15.5.4, but I also tried some things against our production servers which are on 15.10.0, and I guess that’s also what I get in my virtual machines.

The command also works for me in virtual machines, that I spin up locally (using mostly - and I’ve been looking at the few differences - the same configuration as the instance it doesn’t work against?

We also have a script running (made by a colleague of mine) that uses the GraphQL API - but not against that instance, so there is something strange going on.

I looked for a mutation for creating a user without finding one (and as far as I remember you can’t even query - let alone change - the application settings), so we definitely can’t replace our usage of the REST API.
But the GraphQL API mutation to create a runner (for the coming runner registration method) should already be made, whereas the REST API call to do that is still missing. So I was hoping I could get a little more acquainted with that method,

Yes, I’m running into many roadblocks myself with GraphQL, so I’m seriously considering in dropping it and moving to REST, based on the hunch that it’s not mature yet.



We want the GraphQL API to be the primary means of interacting programmatically with GitLab.

In the next sentence it says:

To achieve this, it needs full coverage - anything possible in the REST API should also be possible in the GraphQL API.

And the end of the section says:

There are no plans to deprecate the REST API.

So hopefully we can keep using the REST API for years, and won’t be left without the option of doing something, but dropping GraphQL might be time-limited.