Well, strictly speaking, it doesn't work as advertised, because I was missing the $format. This gives the desired result. http://progetna11.atlas.cm.com/nuget/branch/Packages()?$format=json&$filter=Id eq 'Web'

Thanks. Once I gave the anonymous user delete package privileges, and passed the API key as a header, I was able to accomplish this. However, I find it odd that a successful DELETE call returns nothing.

See: http://inedo.com/support/questions/4487

Yes; the JSON-based REST API allows you to do everything you can from the website, and there's also a simplified job trigger endpoint, where you can do something like POST /api/jobs/trigger/mytemplatname?key=secret123 to trigger a new job. These particular bits aren't fully documented (or implemented in current the v1.0 release) yet, but will be in just a day or so.

The issue turned out to be more of a Nuget issue, I believe. According to Nuget's docs, I should be able to mirror my package by specifying the push package URL in the following format: (proget server)/api/v2/package/. However, this just grabs the first feed under /package. Instead I needed to specify the feed name: (proget server)/api/v2/package/myfeed

Actually, one more comment re: this. It appears that the package ID is synonymous with its name. I thought there was a separate ID value. When I grabbed all packages and versions and tried to serialize in PowerShell, it failed due to the size of the content, so it was good to discover that I can query for the specific package name/ID.

Hello, colleagues. Could you tell me: is something was changed in API in order to create a user with password? Regards, Roman

Sorry, this question somehow got marked as resolved, but it doesn't look like you ever got a response. If you'd like, you can email us at support at inedo.com with details about what you are trying to do, and we can try to give you some more specific help/ideas.

Make sure the ExecutionStart_Date is passed in as UTC.

Just an oversight. It's pretty trivial to change so we can get it in 4.5.3 today.

Using a \ character is correct for escaping in JSON; that should work. We will try to reproduce this, but in the meantime are you able to use single quotes instead in the XML? Assembly='BuildMasterExtensions' should also parse as valid XML if I'm not mistaken.

Yet one more solution (after 6+ months). After trying all the possible solutions mentioned above - if you are still seeing the error: Response status code does not indicate success: 405 (Method Not Allowed). then most likely you need to disable your WebDav IIS plugin. You may either remove the IIS feature from the machine or if you need to keep the feature you may disable it only for this website. You may do this by editing the Web.config file (by default located here: C:\Program Files\ProGet\WebApp) and add two entries as shown below: <system.webServer> <modules> <remove name="WebDAVModule" /> </modules> <handlers> <remove name="WebDAV" /> </handlers> </system.webServer>" Note: the Modules and Handlers section should already exist, you only need to add the line <remove name="xxx"> for each section. I think Proget Dev team should integrate this in the Web.config by default to prevent future issues.. Thanks HS

The XML you have: <ReleaseDeployables><ReleaseDeployables> should be <ReleaseDeployables><ReleaseDeployable> (notice the missing s on the inner element).

If you wrap the first package query in parentheses it should work: http://proget-server/nuget/{feedName}/Packages?$filter=(Id eq 'ProjectName.Deploy') and startswith(Version,'1.0')&$top=1&$orderby=Created desc

It looks like this method was removed as part of the 4.3 executor refactoring; but it will be replaced in a maintenance release (shipping this week). If absolutely needed sooner, you can query the [BuildExecution_ActionGroupActionVariableValues] table direct or via a stored proc.

Check out the BuildMaster API references: http://«host:port»/api/json http://«host:port»/api/soap If you're coding in C#, the SOAP API is probably easier, since it can generate types for you. You'd probably want to call Releases_GetReleases to get a status of all the releases and builds of an application.

Awesome! It looks like the API is working without a hitch in powershell. At this point, we probably have enough to to start with and a few angles to test. If we have any issues with the API or procs, we'll come back here. Thank you!