Unless the site now has access controls on the encrypted URLs (requiring that you first authenticate - prove your identity - and then that the server checks whether your identity is authorised to view that URL), no, it is not safe. Obvious problems include people sharing links through a site like this (without redacting the domain), browsers remembering the URL in their histories (on a shared computer), or somebody (insider or outsider) dumping and sharing a list of valid URLs.
The term used for this type of security vulnerability is a "direct object reference", when inputting an object's ID lets you access the object even if you wouldn't normally have access. The only true solution to the problem is proper access controls. Merely making it hard to guess the object ID doesn't solve the problem, although in the short term it may make exploitation harder. Putting secrets in the URL doesn't really solve anything; you need a system that relies on actual credentials.
Now, as for the enumeration: as the comments point out, that's a very suspect encoding. The repeated prefix indicates that, whatever else they're doing, they aren't using a secure hash (or not using it correctly). Given that they're presumably trying to map from a URL back to an object identifier, it's probably a reversible encoding anyhow.
Encrypting the URL query string with a secret key known only to the server will produce hard-to-guess links, although depending on the type of encryption used it may still be possible to flip bits and produce new valid URLs without knowing the encryption key (they'd need to add an integrity check, like an HMAC or an authenticated encryption scheme, to prevent this). Encryption, by itself, does not prevent an attacker from tampering with the ciphertext (and with some encryption schemes that tampering is easy). In any case, such a system is dependent on the key remaining a secret, making a single point of failure.
Encrypting the query string using a known key - for example, if the key is in that unchanging prefix - is completely broken. Figuring out the crypto scheme used would take a little bit of (educated) guessing and checking, but the space of possible systems would take very little time to search. Once it's known, crafting valid URLs is trivial.
The least-bad way to do this (there's no good way; for anything sensitive you simply must use authentication and access controls) would be to store reasonably-long (64+ bits; GUIDs are often used here), cryptographically-secure random identifiers for every row in the database. Then encrypt them, with a server-side secret key, before turning them into URLs. This avoids single points of failure (the random IDs are useless without the key, and vice-versa) for compromising the whole list of valid URLs, and also means you could do things like periodically changing the ID tokens to invalidate old URLs for those objects, or changing the encryption key to invalidate all old URLs. It'd be secure against bit-flipping the ciphertext because there's no way to say "assume this part is a number, then try flipping bits to produce another valid number"; the valid combinations of bits are an unguessable-small part of the search space of possible identifiers, because the identifiers aren't sequential and are long enough that only an infinitesimal fraction of them will ever be used. But, I must emphasise again: this is a much worse idea than just putting proper authentication and authorization in place. If you've done that, you can safely stick to simply incrementing numeric identifiers because guessing the next value doesn't gain an attacker anything.
