Hi,

Hope you’re doing good,

Please send me a screenshot of what you are entering and what is the message you are getting

You can email me privately via the contact form on my profile page or altumcode.com/contact

Regards,

AltumCode.

These is no need for a screenshot, we are entering the information that is requested on this form and API is not returning any values, it’s coming back blank. Please make sure your approval process works or provide us the exact steps that need to be performed.

Hi,

If there was no need, I wouldn’t have asked for it.

You have provided no context over what is actually happening, what message or what is happening on your side.

Since this is the only such occurrance, I need more details – but you have provided none.

Once again, I wouldn’t have asked for more details if I wouldn’t have needed more details.

https://send.altumco.de/avkcukf/

I just ran the installation right now again, there are no issues on my end, nor has any other customer reported any installation issues.

I’m waiting for more details so I can actually help you.

Regards,

AltumCode.

The only thing I can make an assumption based on not much context is that you maybe have not added the right data in the License Key field when installing.

1 – Go to the downloads page here on codecanyon, click the download button and you will find the license certificate

2 – Inside of it, you will find the Purchase Code – also known as the License Key

Example: https://send.altumco.de/s8kzovd/

Please confirm or share more details.

Regards,

AltumCode.

The reason I said it is not needed, the information you are looking for from the screenshot that is not a requirement mentioned on your product for purchase.

Because your form is asking for 1. License Key – that is a product key, that we have added. 2. Website URL – That we have provided (you have no requirement of knowing) 3. Host – localhost 4. Database Name – That is our database name (again no need for you to know) 5. Database Password – That is our password (again no need for you to know) 6. Subscription – which is optional -

And after adding this we get error for 500 saying – An error occurred trying t load the resource.

If there is any specific requirement for that, make it public here.

I am simply asking for a screenshot for more context.

A screenshot is something that might help me understand what you are dealing with, not a requirement that must be written in the documentation.

Since now you said a 500 error, which gives me a tiny bit more data to work with

I can assume that your files were either not fully uploaded or you have some file permission issues

If you want me to debug it for you

I am more than happy to do so, but I will need the details of your FTP and the installation credentials

I will use them to try and run it on your site, understand whats going on and fix it for you

Otherwise, how can I know whats going on your own host and site and what you might have done wrong?

I’ve dealt with thousands of customers, I don’t care about your license key, database details or what not. I have no use for them, I’m only trying to help you out.

We will not be sharing any FTP details.

We followed the steps outlined in your documentation (https://66audit.com/docs), but your API is not providing a valid response. The 500 error indicates that the issue lies with the API endpoint, and it seems that your server is failing to process the request. Therefore, the issue is on your side, not ours.

Additionally, the information you are requesting is unnecessary and not in accordance with Codecanyon’s guidelines.

We have raised a case and will be requesting the cancellation of this purchase. We also want to clarify that we do not have any concerns regarding the number of customers you have or how you plan to use this information. However, requesting details when the issue is clearly on your side is not appropriate.

Hello once again,

Your deduction is completely wrong.

The 500 error does not come from my API in the first place.

The request goes to your internal installation, my API only validates your license and does not return errors.

Imagine this: You are calling a mechanic that you see an error on your car’s dashboard.

You do not tell the mechanic what you see, you do not bring in the car for service – yet expect it to be fixed.

Explain to me how the issue comes from my API when I just shared a screenshot with you that a test installation was successful?

Do you also want a full video recording to prove that? If yes, I can share.

If you do not upload your files accordingly, or you (or your developers) miss steps in the installation, or even your webhost has something going on – then 500 errors will happen because of mistakes.

I am simply asking for details in order to HELP YOU. NOT to do anything with your credentials.

The product has absolutely no issues, nor does the API. I can 100% prove to you that your issue comes from mishandling the file uploads, requirements, or webhost issues.

This is literally the first time someone is asking for help, yet seems like they do not want to cooperate with anything in actually getting issues solved.

It is common sense to have a simple and cooperative back and forth with a developer if you want help. There does not have to be any guideline for that.

Regards,

AltumCode.

Also, I stated the number of customers because I do not care about your private data – nor do I intend to do anything malicious with it.

For all I care you can provide fully temp data, I will check and show you what you are doing wrong and then you can delete it fully and reinstall on your own.

Not sure how you came to the conclusion that the 500 error comes from my API – because it does not, it comes from your own server – since the Installation request goes to your own files/server first.

So again – if you want me to help you, I’m more than happy to do so – but you should cooperate with proper back and forth.

You’re expecting me to tell you what’s wrong with 0 details, when no other customer has any such issues as you.

Regards,

AltumCode.

Hello there again, TEDevelopers

Hope you’re doing good,

There is no privacy or security risk with this implementation because audits are not accessible randomly by people.

Only the ones who create them are actually having the permissions to access them.

You are suggesting enforcing ownership checks, but not sure how you came to the conclusion that there are no ownership checks – because there are and once again, there is no such issue with privacy and security.

Regards,

AltumCode.

Please test these URLs while logged out / in incognito:

https://seo.dev.eg/audit/2 https://seo.dev.eg/audit/3

They load full audit data without authentication or ownership validation, which confirms an IDOR-style exposure.

We can’t accept this behavior, as it puts our clients’ audit data at risk.

If you believe the current implementation is correct, please propose a concrete solution within the script to prevent public access to the audits we run for clients. At a minimum, access must require authentication and ownership checks.

We need your recommended fix to secure client audit data.

Are these URLs actually set as Public audits or are they set as private?

Regards,

AltumCode.

Check the details from the edits.

https://qr.dev.eg/seoaudit

Kindly share your website link, admin login and FTP details privately – I will take a look to see whats going on your side

You can share them privately via the contact form on my profile page or altumcode.com/contact

Regards,

AltumCode.

Done: Your message has been sent.

Thank you

I replied.

Regards,

AltumCode.

Thank you

This confirms the behaviour is correct -> https://send.altumco.de/fwdhi1l/

Set to public -> works logged out

Set to private -> does not work when logged out (it will only work on the same IP that generated the report even if logged out)

Regards,

AltumCode.

We want to clarify an important design decision before moving forward.

Our plan is to make website scanning and audits free and publicly accessible for everyone. Because of that, using URLs like /audit/1, /audit/2, and /audit/3 is not suitable, even if access control exists.

Numeric IDs:

Are not SEO-friendly

Are easily guessable

Don’t reflect the audited website

They are not appropriate for public audit reports

Since audits will be public by design, we need the audit URL to be a permalink based on the audited website, not an internal ID.

Example direction:

/audit/www-dev.eg

/audit/qr-dev-eg

or a sanitized/hashed version of the domain

This approach:

It is much more SEO-friendly

Makes public audit pages clear and shareable

Avoids exposing internal numeric IDs

Fits the “free public audit” model better

Please confirm:

If changing the audit output URL to a domain-based permalink is possible

Your recommended implementation (slug, normalized domain, hash, etc.)

How existing audits would be handled after this change

We need to move away from numeric audit IDs and align the URL structure with public audits.

I understand,

However – this is how the product was designed to work, and not on other types of URL slugs.

Since this is a particular decision that you personally want to take, it will be possible with custom work into the product files

But not by default and right now, its not something I can confirm that I will personally implement for the whole 66audit suite (since again, this is the first time someone has ever suggested or had any issue with this).

I can definitely say that I will take it into consideration for future updates based on what other customers will also suggest.

Regards,

AltumCode.

We understand this is how the product was originally designed.

However, we want to be very clear on something important from a business and market perspective.

This is the second product we’ve purchased from you, and we are not using it as a small internal tool. We are using it at agency scale, under a public brand, and as part of a free public audit model. Feedback coming from this level is not a “personal preference” — it reflects how large agencies and SaaS platforms think and operate.

When agencies at our level raise concerns or suggestions like this, it’s usually because:

We’ve seen similar models succeed or fail.

We design tools for public use, SEO visibility, and long-term trust.

We think in terms of scalability, adoption, and market growth.

Public audit URLs based on numeric IDs may work technically, but they do not align with:

Modern SaaS audit platforms

SEO-first public tools

Agency and enterprise expectations

We are not suggesting this only for our use case. We are suggesting it because this kind of improvement elevates the product to a higher market level, opens it to broader use cases, and makes it more attractive to agencies and serious buyers worldwide.

We strongly believe that listening to feedback from agencies actively deploying this at scale is an opportunity to evolve the product, not a criticism of its current design.

We hope you can reconsider this point from a business growth and product evolution perspective, not only from the original implementation scope.

I totally understand and appreciate your suggestion,

I will explain here 2 big issues with your suggestions

1 – You can not put the domain name or full URL in the actual url like this:

domain.com/audit/altumcode.com

Why? Because if another user wants to audit altumcode.com – he will get the same URL and he will access (as you’ve also said) potentially private information on past audits of altumcode.com

On the same note, this format would not work when auditing large links like:

altumcode.com/demo/page.php?link=1&another_link=2…etc

As you would not be able to fit such URL inside of domain.com/audit/URL_HERE

2 – using domain.com/audit/f0824015-bc2e-46cb-a123-7ff6d09df263 is much slower in terms of performance compared to using IDs as they currently are

the only “pro” in terms of this choice is the potential privacy aspect, but this also does not make sense – because all audits are public, therefore they will be indexable and they can be found on google and other search engines.

So this argument completely fails as well

Regards,

AltumCode.

Thanks for the detailed explanation — this helps clarify where the disconnect is.

We agree with you that:

Full URLs should not be stored directly in paths

Multiple audits of the same domain must not collide

Internal numeric IDs are optimal for performance and storage

However, we suggest not replacing your internal ID logic.

What we are proposing is a public URL layer decoupled from internal IDs, which is standard in public audit tools.

Proposed hybrid approach (no core logic break):

Keep numeric IDs internally (DB, relations, performance)

Expose domain-based permalinks publicly

Map domain → latest audit ID internally

Example:

Public: /audit/dev.eg → resolves to the latest audit ID internally

Internal: audit_id = 12345

Optional extensions:

/audit/dev.eg/history /audit/dev.eg?run=2024-09-18

This avoids:

ID exposure

Guessable URLs

Poor SEO structure

And solves:

Repeated audits of the same domain

Long URLs with parameters

Performance concerns

This is not a privacy-only argument — it’s about public SEO architecture and product positioning for agencies and SaaS use cases.

We’re not asking to remove your current design, only to add a public-facing routing layer on top of it.

This would significantly expand the product’s usability for:

Agencies

Public tools

SEO marketing funnels

We strongly believe this would elevate the product to the next level without breaking its core.

I kindly reply with asking, are these AI replies? As everything seems so robotic and typical AI. I would highly and kindly ask for you to not use AI to keep generating replies and use your own words and your own suggestions.

Using /audit/dev.eg (for example) to map to the latest audit is again incorrect, as the latest audit can be for dev.eg/page/contact-form and not the main domain.

Using date timestamps in URLs is also incorrect in terms of both performance and uniqueness, as with your proposal:

- Different users will have the same pathing for the same domains (incorrect based on your original privacy reasoning)

- You will have the same duplicated pathing for multiple audits on the same day due to the /audit/dev.eg?run= query in the URL

- You will also not be able to differentiate different pages on the domain

I kindly urge you to re-read what was said in this topic so that we do not go in circles due to AI responses that keep on suggesting different reasons that are completely context-less.

Regards,

AltumCode.