# Identifiers Every item operation has an identifier in its URL. Although this identifier is usually a number, it can also be an `UUID`, a date, or the type of your choice. To help with your development experience, we introduced an identifier normalization process. ## Custom Identifier Normalizer > In the following chapter, we're assuming that `App\Uuid` is a project-owned class that manages a time-based UUID. Let's say you have the following class, which is identified by a `UUID` type. In this example, `UUID` is not a simple string but an object with many attributes. ```php ``` Once registered as an `ApiResource`, having an existing person, it will be accessible through the following URL: `/people/110e8400-e29b-11d4-a716-446655440000`. Note that the property identifying our resource is named `code`. Let's create a `DataProvider` for the `Person` entity: ```php getTimestamp() } /** * {@inheritdoc} */ public function supports(string $resourceClass, string $operationName = null, array $context = []): bool { return $resourceClass === Person::class; } } ``` To cover this use case, we need to `denormalize` the identifier to an instance of our `App\Uuid` class. This case is covered by an identifier denormalizer: ```php getMessage()); } } /** * {@inheritdoc} */ public function supportsDenormalization($data, $type, $format = null) { return is_a($type, Uuid::class, true); } } ``` Tag this service as an `api_platform.identifier.denormalizer`: ```yaml services: App\Identifier\UuidNormalizer: tags: - { name: api_platform.identifier.denormalizer } ``` ```xml ``` Your `PersonDataProvider` will now work as expected! ## Changing Identifier in a Doctrine Entity If your resource is also a Doctrine entity and you want to use another identifier other than the Doctrine one, you have to unmark it: ```php