How to use our attractiveness test in your own projects

An attractiveness score can be one small feature inside a much larger product. You might be creating a photo feedback tool, a dating profile assistant, a social experiment, a mobile app, or an internal prototype. In each case, the useful question is not how to recreate the entire scoring system. It is how to add the result to your project in a way that is secure, understandable, and respectful of the person in the photo.

Our attractiveness test is available through an API. Your project sends a portrait, the API analyzes it, and your application receives structured result data that it can present in its own interface. You can learn about access at AttractivenessTest.com/api or AttractivenessAI.com/api.

This article explains where the API can fit, what an integration needs, how AI coding tools can help, and which privacy and product decisions should be made before launch.

Where an attractiveness score can fit

The score does not need to be the whole product. It can support a focused feature inside several kinds of projects.

Photo feedback tools

A photo tool can compare how lighting, camera angle, expression, or framing changes the model's response. This works best when the app explains that it is comparing photos rather than making a final judgment about a person.

Dating profile assistants

A profile assistant might let someone review several photos and decide which one to use first. The score can be one signal alongside image quality, facial visibility, variety, and the user's own preference. It should not be presented as a promise of more matches.

Games and entertainment

The API can support an opt-in party game or a playful result screen. Even in an entertainment setting, the interface should avoid humiliating language, public rankings without consent, or surprise analysis of another person's photo.

Research and product prototypes

A researcher or product team can use the API to explore interface ideas without training and hosting a computer vision model. It is still important to review consent, sampling, bias, and local data protection requirements. The API result is a model estimate, not a validated measure for medical, employment, insurance, education, or other high-impact decisions.

Why use the API instead of recreating the model

Building the scoring system from scratch is difficult. It requires a large and appropriately licensed image dataset, consistent human ratings, face detection and alignment, model training, evaluation across different groups, and infrastructure that can process images reliably. The model also needs ongoing monitoring and version management.

Using the API lets your project treat scoring as a service. You can focus on the purpose of your feature, the user interface, and the way results are explained. You still control everything around the request, including when a photo is submitted, what data is displayed, and whether your own application stores anything.

This division is useful even for experienced developers. For a prototype or a smaller project, it can remove months of machine learning work. For a larger product, it separates the scoring workload from the rest of the application.

What the API provides

The API accepts one portrait as either a base64-encoded image or a public HTTPS image URL. A successful response includes:

score, which is the direct model result
score_adjusted, which applies the service's presentation adjustment
api_version, which identifies the response version

Optional fields can include a face boundary box, a cropped face, and a gender result. Request only the fields your project actually uses. For example, a simple result screen may need only one score and the API version. Leaving out unnecessary personal attributes keeps the integration easier to explain and maintain.

The API also returns structured errors. If no face is detected, your application can identify the error code and ask the user for a clearer, front-facing portrait. This is more reliable than trying to interpret the wording of an error message.

Decide how the result will be used before writing code

A clear product definition prevents many problems later. Write down the answers to these questions first:

Who is allowed to upload a photo?
Must the uploader be the person shown in the image?
What does the score help the user do?
Which score will the interface display?
Will photos or results be stored by your application?
How will a user delete stored data?
What explanation will appear beside the result?

The wording matters. "The model's estimate for this photo" is more accurate than "your attractiveness." Lighting, camera position, expression, image quality, and styling can all affect the result. Attractiveness is also subjective and shaped by personal and cultural preferences.

If the feature has no clear benefit beyond ranking people, reconsider the design. Comparisons that help someone choose between their own photos are generally easier to justify than leaderboards built from photos of many people.

A simple integration structure

The safest common structure has three parts:

A browser or mobile interface accepts the photo and shows a preview.
Your backend receives the image and sends it to the attractiveness API using a private access token.
Your backend returns only the result fields needed by the interface.

The request flow looks like this:

text User interface -> Your backend -> Attractiveness API User interface <- Your backend <- Result data

Do not place the API token in browser code or a public mobile application bundle. A visitor can inspect client-side code and reuse an exposed credential. Store the token as a server-side environment variable instead.

Your backend sends exactly one image source using face_image for base64 data or face_image_url for a public HTTPS address. It should set a timeout, limit request size, and avoid logging the request body. On success, it can pass the selected score to the interface. On failure, it should return a short message that tells the user what to do next.

Using Claude or another AI coding tool

You do not need traditional developer skills to create a first version. Claude and other AI coding tools can generate the upload page, backend function, and result screen from a written description. A no-code or low-code platform can also work if it supports secure server-side API requests.

Give the tool specific requirements instead of asking it to "make an attractiveness app." For example:

Create a mobile-friendly photo feedback feature. Let the user select one portrait and preview it locally. Show a short consent and privacy notice before submission. Send the image to a server-side function, where the API token is stored in an environment variable. Display the returned score as an estimate for this photo. Handle invalid files, timeouts, and a no-face-detected response. Do not store the uploaded image or include it in logs.

Then ask the tool to explain where the token is stored, which code runs in the browser, and which code runs on the server. This helps uncover a common mistake where a supposedly private token is included in the public frontend.

AI-generated code still needs testing. Check the project on a phone and a desktop computer. Try unsupported files, large images, photos with no visible face, slow connections, repeated clicks, and temporary server failures. If the project will process many photos or operate commercially, have an experienced developer review its security and data handling.

Design a useful upload experience

Good input guidance reduces errors before they reach the API. Ask for a clear portrait with one visible face, even lighting, and little obstruction from hair, sunglasses, or hands. Let the user preview and replace the image before submitting it.

Validate common file formats and file size in the interface. Very large photos can be resized before upload while keeping their aspect ratio. This reduces transfer time and makes the application feel more responsive.

Do not submit a photo immediately after it is selected. Wait for a clear action from the user. Place the privacy notice and any consent checkbox before that action so the person understands what will happen.

While the request is running, disable duplicate submissions and show a loading state. If analysis fails, keep the message practical. "We could not find a clear face. Try a front-facing photo in better light" is more helpful than a generic technical error.

Present the result in context

A number without context can feel more authoritative than it is. Label the result as an AI estimate and explain that it applies to the submitted photo. If the project compares several images, keep the model version and displayed score type consistent so the comparison is meaningful.

Avoid insulting categories or language that treats a score as a person's value. Do not use the result to make decisions about hiring, credit, healthcare, education, access, or other consequential services. The feature is better suited to entertainment, creative experiments, and personal photo feedback.

You can also give the user control over visibility. Results should be private by default. Sharing should require a separate action, and the interface should clearly explain what will become public.

Privacy responsibilities

The attractiveness scoring API processes submitted photos without saving them. That protects the image at the scoring layer, but the privacy of the complete project also depends on your own systems.

Avoid storing the upload in your database, temporary file system, analytics platform, or error logs. Check whether your hosting provider and monitoring tools capture request bodies. Use HTTPS throughout the request path and collect only the information the feature needs.

If your project intentionally offers history or sharing, make storage optional. Explain what is stored, why it is stored, who can view it, and when it will be deleted. Provide a simple deletion method. Require the uploader to have permission from the person in the image, and consider age restrictions before allowing minors to use the feature.

Privacy claims should describe the entire system accurately. Do not say that photos are never stored if your own application, a third-party image host, or a logging service keeps a copy.

Handling growth and larger request volumes

The API is designed to scale the scoring layer, so your project does not need to operate model servers or manage machine learning workers. Your application still needs basic traffic controls.

Add rate limits, resize oversized images, prevent duplicate submissions, and use sensible timeouts. Decide what the interface should show if the API is temporarily unavailable. For a public launch, estimate monthly request volume and discuss the appropriate access level in advance.

Monitor response times and error codes rather than photos. Anonymous operational data can show whether users are encountering unclear images, upload limits, or network failures without creating a collection of face images.

A practical launch checklist

Before making the feature public, confirm that:

the API token is stored only on the server
photos are not written to application logs
the uploader sees a privacy notice before submission
the interface asks for consent and permission to use the photo
only necessary response fields are requested
errors give clear instructions without exposing technical details
results are described as estimates for a specific photo
sharing is optional and private by default
rate limits and timeouts are in place
the feature has been tested on mobile and desktop devices

Final thoughts

Using our attractiveness test in another project is mainly an integration and product design task. The API supplies the scoring result, while your application decides when analysis happens, how the result is explained, and what happens to the photo before and after the request.

Claude or another coding tool can help create the technical pieces even if you are not a developer. The most important work is still human: choosing a reasonable use case, protecting the API token, respecting consent, minimizing data collection, and presenting the result without claiming more certainty than the model can provide.