@anlambert is this done and, if so, can you close it?

Related comments:

• the doc page https://archive.softwareheritage.org/api/1/origin/ includes as return fields the following:

type (string): the type of software origin (deprecated value; types are now associated to visits instead of origins)
id (number): the origin unique identifier (deprecated value; you should only refer to origins based on their URL)

• but it look like both fields are gone, at least from the example output at https://archive.softwareheritage.org/api/1/origin/https://github.com/python/cpython/get/

So I think (a) this task should be closed, (b) those two fields should be removed from the doc.
(But I could totally be missing context here!)

@zack, I take care of cleaning the Web API documentation and then we can indeed close that task as resolved.

Quick follow up on this, we are still leaking origin ids for the [[ https://archive.softwareheritage.org/api/1/origins/ | /origins/ ]] endpoint. There is also still an origin_from parameter to handle pagination.

I known that OpenAIRE is using that endpoint and they already contacted me when we removed the origin type attribute as it broke their code.

I propose to remove those id leaks from that endpoint and contact OpenAIRE to tell them to use the Link header from now on to paginate
the results.

In T1791#41498, @anlambert wrote:

I propose to remove those id leaks from that endpoint and contact OpenAIRE to tell them to use the Link header from now on to paginate
the results.

Sounds good.

As a minor variation I propose to take this chance to streamline & generalize the process of informing people about API changes. Rather than mailing OpenAIRE folks only, let's mail swh-devel with an appropriate message, say, 1 week before the change. (Given it's the first time we can also inform the OpenAIRE folks about this, but making clear in the future announcements will be sent via the list.)