Updates from daily today:

• For statement invalid field error, we'd add the actual field that is incorrect also in the path. Example - /property_id/0/rank
• For statement missing field error, we'd would not do this because the field is actually missing and it doesn't make sense to add it to the path. But, we should add a new field called field in the context which names the actual field that is missing [insert clown emoji here]

Update from daily and my check:

1. Remove the validation check for having at least a label or a description in a language (Ticket description will be updated)
2. The statement group property id vs statement property id mismatch error occurs only when two separate *existing* property IDs are used, or as long as the property id of the statement inside the group exists.

If the property id of the statement inside the group does not exist, instead of the mismatch error, we get a "statement-data-invalid-field"

I'd propose as long as the property id does not exist, regardless of where it is, we should throw the "statement-data-invalid-field"

Hi @Ifrahkhanyaree_WMDE. I am waiting to use the Create Item API in my tool (https://bub2.wmcloud.org) to automatically create Wikidata entries for the metadata for the book. I could use action=wbeditentity but I prefer to use the Wikibase APIs for interacting with Wikidata. Any idea by when will this be live for production use?

Hiya @wassan.anmol117, we should have the endpoint live by next week! Ideally early next week but most definitely end of next week

Checked the two changes and a few extra things for good measure, so @WMDE-leszek doesn't have to go through every single thing. I think we're ready for it to be marked as production ready

In T342990#9836894, @Ifrahkhanyaree_WMDE wrote:

Hiya @wassan.anmol117, we should have the endpoint live by next week! Ideally early next week but most definitely end of next week

Thanks. Can't wait to use it! :)

@wassan.anmol117 this has been enabled on master and will go live on wikidata.org with the next train on Wednesday 5th June :)

In T342990#9850211, @Ollie.Shotton_WMDE wrote:

@wassan.anmol117 this has been enabled on master and will go live on wikidata.org with the next train on Wednesday 5th June :)

Awesome, thanks!

@Ollie.Shotton_WMDE @Ifrahkhanyaree_WMDE Did this go live yesterday? I tried testing the API on Postman but it is giving me the following error even after I am sending a POST request:

{
    "messageTranslations": {
        "en": "The request method (GET) was not the allowed method for this path (POST)"
    },
    "httpCode": 405,
    "httpReason": "Method Not Allowed"
}

This is the endpoint that I'm trying to hit: https://wikidata.org/w/rest.php/wikibase/v0/entities/items

Hi @wassan.anmol117, it's live on Wikidata since yesterday. Have you explicitly selected the method to be POST when testing it on Postman? I think it needs that even after the body has been defined

Let us know if that helps!

Yes, I've selected that.

Hi @wassan.anmol117,

What version of Postman are you using? Have you tried alternative tools, or something like curl on the command line?

This curl command returns a label-description-same-value error for me (as expected):

curl --request POST \
  --url https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items \
  --header 'Content-Type: application/json' \
  --data '{ "item": { "labels": { "en": "test" }, "descriptions": { "en": "test" } } }'

In T342990#9867087, @Ollie.Shotton_WMDE wrote:

Hi @wassan.anmol117,

What version of Postman are you using? Have you tried alternative tools, or something like curl on the command line?

This curl command returns a label-description-same-value error for me (as expected):

curl --request POST \
  --url https://www.wikidata.org/w/rest.php/wikibase/v0/entities/items \
  --header 'Content-Type: application/json' \
  --data '{ "item": { "labels": { "en": "test" }, "descriptions": { "en": "test" } } }'

@Ollie.Shotton_WMDE I think I have found the issue. As per the Wikidata REST API documentation, the endpoint should be https://wikidata.org/w/rest.php/wikibase/v0 but the endpoint in your comment has www as well. I tried with adding www in the endpoint and it worked.
But I think the API should work even without www.

Ahh, right, yes! So what is happening here is that wikidata.org is redirected, via a "301 Moved Permanently" response, to www.wikidata.org. Postman is automatically following this redirect but changing the POST method to a GET method, hence the error you saw. You can see this redirect if you turn off Automatically follow redirects in Postman's settings. This is a client issue and not something we can change in the Wikibase REST API.

We have changed the Wikidata REST API documentation to now include the www. so others are less likely to trip over this issue. We have also brought this to the attention of the Wikidata team to see if a "308 Permanent Redirect" would be a better redirect response to return, as clients shouldn't change the HTTP method when following a 308 redirect.

Side note, I suggest you use test.wikidata.org while testing the Create Item endpoint to not spam wikidata.org with empty/test Items. :)

Sure. Thanks @Ollie.Shotton_WMDE!

@Ollie.Shotton_WMDE @Ifrahkhanyaree_WMDE While using the API, I observed that I was able to make a POST call with unauthenticated API requests. For example, I created this item on https://test.wikidata.org without the Authorization header and it worked. Is this expected?

Hi @wassan.anmol117, yes, that is to be expected. Just like via the Wikidata UI, you can create anonymous edits that will be associated with an IP address (in the future this will be temporary anonymous accounts). If you want your edits to be associated with a particular account, then you would need to authenticate. There are other benefits to authenticating, such as an increased rate limit.

In T342990#9874495, @Ollie.Shotton_WMDE wrote:

Hi @wassan.anmol117, yes, that is to be expected. Just like via the Wikidata UI, you can create anonymous edits that will be associated with an IP address (in the future this will be temporary anonymous accounts). If you want your edits to be associated with a particular account, then you would need to authenticate. There are other benefits to authenticating, such as an increased rate limit.

Alright, got it. Thank you.