[Support Guide] Linking a repository via API

Hi, @brunocc. You must also create a webhook for the site at Netlify and then add that webhook to GitLab so their service will trigger builds at Netlify when a push to the upstream repo occurs.

Our API cannot do this at GitLab. The GitLab APIs are used for this.

When you add a site using GitLab via the web UI we create the webhook using our API. We use your GitLab credential to make API calls at GitLab to add the new webhook to their service. This is how GitLab tells Netlify when a new commit occurs.

So, there are two extra steps:

  1. Make an API call at Netlify to make a new webhook for the site.
  2. Make an API call at GitLab to add that webhook to the repo.

If you do this in our web UI and open the browser devtools you will be able to see the exact API calls made to do this and what JSON content the API calls required in the Network tab.

When those steps are completed commits to the GitLab repo will trigger builds at Netlify. If there are questions about this, please let us know.

@fool it might be worth updating this post to explain that the repo id for bitbucket accounts consists of workspace/repoName rather than an integer id

great suggestion! Just updated that:

Note that there are two ID’s there - a GitHub repo ID (which you can get from their API ) - and similar ID’s are needed for GitLab and BitBucket as well - though for bitbucket at least the ID will have the format login/project instead of being a literal ID number.

Think that makes it clear enough? Do you think I need to call it out further anywhere else? You are my target audience so happy to take your suggestion, @shallow_alchemy :slight_smile:

I think that’s a perfect place to call it out, @fool . just one thing: mine isn’t login/project it’s workspaceName/project. My personal login has several workspaces.

thanks - updated per your advice - does that seem correct to you now? (I don’t use workspaces, so I think login/project is still correct for e.g. this repo of mine: Bitbucket)

1 Like

Hey everyone, hope you’re doing good. My issue is simple: I want to create and deploy a Nextjs site (server rendered) via the netlify api, but it seems to only consider static deploy. Is there a way to tell i want to use Nextjs runtime during the build with the api? Thanks a lot

Hi :wave:t6: @lemed ,

Yes, you can specify the runtime for your Next.js site when creating it via the Netlify API. You need to include the plugins field in your API payload and specify the @netlify/plugin-nextjs package. Here’s an example of how to do it:

{
  "plugins": [{
    "package": "@netlify/plugin-nextjs"
  }]
}

This setting should be included in the /sites/<site-id>/ endpoint of your API request.

For server-side rendered Next.js apps, the typical build settings are as follows:

  • Build command: next build
  • Publish directory: .next

You can include these settings in the repo section of your API payload.

1 Like

Hi!
I’ve successfully created a site through the API following all the steps provided. In my case they were:

  1. Create a deploy key on Netlify.
  2. Add the deploy key to the repo on GitHub.
  3. Create the site on Netlify.

The payload I used to create the site is the following:

{
  name,
  build_settings: {
    public_repo: false,
    stop_builds: true,
    installation_id: GitHubNetlifyApplicationId,
  },
  repo: {
    branch: "main",
    cmd: "npm run build",
    deploy_key_id: deployKeyId,
    dir: ".next",
    private: true,
    provider: "github",
    public_repo: false,
    stop_builds: true,
    repo: GitHubStaticSiteRepoName,
    repo_id: GitHubStaticSiteRepoId,
  },
  plugins: [
    {
      package: "@netlify/plugin-nextjs",
    },
  ],
}

However, as soon as the site is created, a deploy is triggered. This is not the desired result, since I’d like to add some environment variables first. As a result, since the env vars are missing, the deploy fails.

So, my main question is if is there any way to just create the site and not trigger a deploy? This way I can add the environment variables and then manually trigger a deploy.

And another question is related to the payload shown above. It’s not a blocker, but just out of curiosity: what’s the difference between the keys public_repo and stop_builds inside build_settings and repo? Are they redundant? Should I remove them from either build_settings or repo?

Thanks!

One more thing. It seems that the server is ignoring two params I’m passing in the payload to create the site. That would explain why it’s triggering a deploy when I firstly create it. But also it’s ignoring the installation_id param. Is this expected? What am I doing wrong?

The response from the server is something like:

{
  [...]
  build_settings: {
    [...]
    stop_builds: false,
    installation_id: null,
    [...]
  },
  [...]
}