Netlify API deploys missing draft property

Hi, we have a feature that depends on knowing whether or not a deploy was a draft. The listSiteDeploys docs for the api state that the draft property would be sent in the response, but our responses from the API are lacking that property.

We are using the js-client to consume the API from a Node application.

Sample response:

{
      "id":"618c1336ed517213e60df2db",
      "site_id":REDACTED,
      "build_id":"618c1336ed517213e60df2d9",
      "state":"error",
      "name":"sandbox-straightforward-toad-618bcff9885ea2ecc10cb733",
      "url":REDACTED,
      "ssl_url":REDACTED,
      "admin_url":REDACTED,
      "deploy_url":REDACTED,
      "deploy_ssl_url":REDACTED,
      "created_at":"2021-11-10T18:45:10.571Z",
      "updated_at":"2021-11-10T18:45:13.601Z",
      "user_id":REDACTED,
      "error_message":"SOME ERROR NOT RELATED TO THIS",
      "required":[
         
      ],
      "required_functions":null,
      "commit_ref":null,
      "review_id":null,
      "branch":"main",
      "commit_url":null,
      "skipped":null,
      "locked":null,
      "log_access_attributes":{
         REDACTED
      },
      "title":null,
      "review_url":null,
      "published_at":null,
      "context":"production",
      "deploy_time":null,
      "available_functions":[
         
      ],
      "screenshot_url":null,
      "site_capabilities":{
        REDACTED
      },
      "committer":null,
      "skipped_log":null,
      "manual_deploy":false,
      "file_tracking_optimization":true,
      "plugin_state":"none",
      "has_edge_handlers":false,
      "links":{
         REDACTED
      },
      "framework":"not_fetched",
      "entry_path":null,
      "views_count":null
   }

Hi @GonzaloHirschToptal,

Is this happening for deploys that are a draft? My guess is that, the property could be skipped for deploys that are not a draft like the one you’ve got now.

I’m creating site builds and marking them (all with the API) as draft: true after the creation.

Could you clarify your use case by trying to do that?

Because from what I see, the above deploy is still not reflected as a draft to our backend:

image

Have you marked that as draft too?

I don’t remember if that exact one was a draft, but the following build_id (618ea9a8f95789114eb86cb5) for that same site should be marked as draft: true. The deploy_id for that one is 618ea9a8f95789114eb86cb7.

Thanks for the quick responses

That one is not marked as draft either:

image

From what I know, draft property is automatically handled by the backend and not supposed to be changed by the user. Could you clarify what exactly you’re trying to do?

We are building some custom deploy previews using locked builds (it was recommended to me in another thread here), and I want to be able to determine which build was a preview and which was a production build. I aim to tag previews as draft: true to differenciate them.

Is this the thread you’re referring to:

Yes, that exact one. We tried it and it works perfectly.

The draft property is used as an entirely different feature so manually updating that should not be possible. You can give the updateSite API call a try if you’re not already doing it, but that would cause weird behaviour in the UI as that’s programmed to handle it differently.

I think the only thing you can do is try something in the commit message. You could maybe prefix the production commits with prod and check for that value.

We are not using git-based deploys, and I’m not sure we can edit that because the updateSiteDeploy docs don’t specify that as a property I can update.

Using the deploy title could work in that case, but that property isn’t listed as something the API can receive, and we are triggering deploys via builds.

Oh yeah, I’m sorry. That’s not the API call that would help.

Since you’re manually triggering builds, I’m really not sure what can be done in this case. This doesn’t look like something possible unfortunately.

The docs for updateSiteDeploy mention the draft property, so are you sure it’s not possible to use that?

I do think so, yes. I can run it by the team to confirm though.

Thanks, I appreciate it :slight_smile:

I checked further and I believe it might not be possible with your workflow. If you use CLI, I believe there’s a draft flag that you can pass - not sure if that will be useful here, but there’s no other way unfortunately.

Ok, thank you, I appreciate the help. In case I find a workaround for this, I’ll post it here.