User story and Web Service

Does a product backlog item maps to a user story? Are they the same?

Not necessarily, but in general, they do. Like your scrum master said, other things can be product backlog items, too. However, it depends on how your SCRUM works. Some teams have a separate bug backlog which is taken into consideration for sprints as well, while others keep such things in the product backlog.

Two separate logs make it more difficult for the product owner to prioritize tasks, as now two logs have to be taken into consideration for the next sprint. But they do offer a better oversight and both can be prioritized separately.

So, my question is, what sort of things can get into the Product Backlog as items?

This can be anything which is part of the product vision and the journey to the product you want to create. It mostly contains requirements (user stories) but can also contain actions or technical things that do not directly belong to the product (e.g. "Buy a new server for dev team", "Create advertisement for product"). The backlog should avoid uncessary details and should not try to micromanage technical things. The product backlog can contain anything that delivers value to the product.

There's not the one true Scrum. Sometimes separate backlogs are a better way to manage the product, sometimes they are just in the way. Find out what works for you best.

Since this is tagged scrum, you likely want to defer to a more detailed user story. If you were using something like XP or FDD, you can be a bit more agile because the milestone is not time-based.

With Scrum, you really only want to define the user story enough to be able to adequately give an accurate time estimate - however much definition that requires.

It really depends on the whims of the team and the stakeholders, but if you delineate 10 aspects or subfeatures of editing purchase orders, you aren't likely going to be able to add another once the sprint has been planned, and if one of those subfeatures is involved enough (like removing items from an order, possibly), it may need to be turned into a feature with a story of its own.

It's impossible to do Scrum perfectly, however the end goal of Scrum is not to remove all ambiguity, but rather to clearly define basic functionality to remove enough ambiguity to give a mostly accurate time estimate.