How does a client keep track of which cards it created to prevent incorrectly handling objects created by other systems

One of the most common use cases for our API is to automate provisioning of mobile passes, portion of this use case also entails reissuing passes where ideally we take away the pass that was issued previously. Common scenarios for these are:
- The use has a new mobile device and would like to reenrol for a corporate pass
- Invitation for a pass has expired and the user wants to try again
- General debugging exercise to see if the cypher is faulty

In all these instances it would be nice to be able to clean up the previously issued pass by our middleware. The challenge seem to be as follows:
- When creating a mobile credential through the API it doesn't return a response body to indicate the newly created object
- While we would have the `href` for a `card_type` it is in theory possible for another system (at a minimum the command centre) to create a pass of the same type
- From what I can see the `cards` payload does not have a created or updated date and you can't `GET` the card object on it's own

```json
"cards": [
{
"bleFacilityId": 884878,
"credentialClass": "mobile",
"credentialId": "83010eda-d7ba-4f20-8e9a-3d50ce301425",
"href": "https://commandcentre-api-au.security.gallagher.cloud/api/cardholders/4665/cards/d725c6....",
"invitation": {
"email": "kritis@...au",
"href": "https://commandcentre-ap-southeast-2.security.gallagher.cloud/api/invitations/KQAY-....",
"mobile": "0411....",
"singleFactorOnly": true,
"status": "expired"
},
"number": "0411....",
"status": {
"type": "active",
"value": "Active"
},
"type": {
"href": "https://commandcentre-api-au.security.gallagher.cloud/api/card_types/2550",
"name": "Mobile Credential"
}
}
],
```

I think we should outline some strategies in the documentation as to how we can keep a track of the objects we are creating, also possible to address this in #9