End-user ID requirements

​

The rules in one minute

1. Always send it. Send end_user_id on every request to api.eachlabs.ai that runs a model or a workflow. Treat a missing ID as a bug in your code.
2. One person, one ID. The same person always gets the same ID, forever. Two people never share one ID. There are exactly two exceptions:
   • a shared ID for one business customer that refuses to give you per-user IDs, at your risk;
   • a job ID for an automated job with no person behind it, built from the ID of the employee who owns the job and the job’s name.
   Signed-out visitors are not an exception. Require sign-in, or send one stable ID per visitor at your risk.
3. The last person in the chain. If your customer is a business that serves its own users, get their user’s ID from them and pass it to us.
4. You can name the person. You must be able to identify the person behind every request from the ID plus your own records, and send us that person’s records within 24 hours of our email. This includes signed-out visitors and shared IDs.
5. Pseudonymous. Use your internal user ID or a hash of it. Never put a name, an email address, a phone number or an IP address in end_user_id, hashed or not.

​

Words used on this page

• You: the company that holds the each::labs account and calls the API.
• Your organization: your each::labs account, with all of its members and API keys.
• End user: the human who asked your product for the content: the person who typed the prompt or uploaded the file.
• Business customer: a company that uses your product for its own staff or to serve its own users.
• Flagged: we found apparent child sexual abuse material in a request, or an attempt to request or generate it.
• False ID: another person’s ID, or a value that does not let you trace each request to one person with your own records.
• Permanently suspended or closed permanently: your organization loses access to each::labs for good. Every account, member and API key in it stops working, and you may not open a new account.

​

Why we require it

• US federal law requires each::labs, once it knows of apparent child sexual abuse material, to report it to the National Center for Missing & Exploited Children (NCMEC) CyberTipline as soon as reasonably possible (18 U.S.C. § 2258A).
• A report does the most to protect a child when it identifies the person responsible. When that person is your end user, only you hold the records that identify them. end_user_id links the request we see to the person you know.
• Our report identifies your organization, because the request came through your account. If your end_user_id identifies the person, the report points to them. If it does not, your organization is the only party our report identifies.
• A correct ID also protects you: when one of your end users is flagged, we can block that one person instead of your whole organization.

​

How reporting works under US law

1. We find it. One of our checks or a report flags a file. The Child Safety Policy says which checks are on. A person reviews each flag before we report it. We remove our copies of the flagged files from public access.
2. We report it to NCMEC. The law requires us to report to NCMEC’s CyberTipline as soon as reasonably possible (§ 2258A(a)). A provider that knowingly and willfully fails to report can be fined (§ 2258A(e)).
3. The report says who, when and what. The law lets a report include information that identifies the people involved, when and how the content was uploaded, sent or received, location data and the content itself (§ 2258A(b)). Our report identifies your organization by its each::labs account ID and includes any end_user_id sent with the request, the time of the request and the file. We give NCMEC and law enforcement the records you send us when they ask or the law requires. Outside a report, we disclose the other records we hold when valid legal process requires it. You never send the material to us.
4. NCMEC passes it to law enforcement. NCMEC makes each report available to one or more law enforcement agencies: federal, state or local agencies that investigate these crimes, or certain foreign agencies (§ 2258A(c)).
5. We preserve it. We keep the reported contents for at least one year after the report, as the law requires (§ 2258A(h)).
6. Law enforcement can come to you. An investigating agency can use legal process, such as a subpoena or a search warrant, to require the records you hold about your end user. That is why you must keep the records in Records you must keep.

​

Choose the value

• When to prefix. Put the business customer’s ID in front of the ID of every user who belongs to that customer, as in cust_812:user_4471, even if you have only one business customer. Your own direct users need no prefix.
• Prefixes must not collide. Join the prefix and the rest with a separator that can never appear in the prefix, that is, in any of your business customers’ IDs (a colon works if none of those IDs contains one). The rest may contain the separator, as in the next example. If your business customers’ IDs can contain it, hash the part after the prefix. Otherwise two different people can end up with the same value.
• Deeper chains. Prefix only with your own direct customer’s ID. Your customer sends you a value that is already unique on its platform, built the same way. For example, an agency (cust_812) serving a client (client_33) whose staff member (staff_7) made the request sends you client_33:staff_7, and you send cust_812:client_33:staff_7. The colon is only a convention: any stable format works, as long as two people never get the same value.
• Raw ID or hash. Both are fine. Pick one form and keep using it.
• Length. The API accepts up to 256 characters. Keep the whole value, including any prefix of your own, to 240 characters or fewer: that is the safe maximum.
• Examples are not values. Code samples in these docs use usr_4f9a2c to stand for your real user’s ID. Never copy it into your code as a fixed value.
• Business customers must pass IDs down. Make end_user_id a required field in your own API. Every business customer sends you its end user’s ID with each request, and you forward it to us. If that business customer serves other businesses, the same rule repeats at every level until it reaches a person. Write it into your contracts.

​

A consumer app, step by step

1. We remove our copies of the flagged files from public access, and we can permanently block usr_4471 in your organization.
2. We report it to NCMEC, as US law requires. The report identifies your organization by its each::labs account ID, with usr_4471 as the end user. See How reporting works under US law.
3. We email your organization’s owners, unless the law or law enforcement requires us not to. Within 24 hours of that email, you ban the user from your product, send their records to [email protected] and confirm the ban in the same email. The records are listed in Records you must keep.
4. If you cannot identify the user, your organization is the only party our report identifies, and we permanently suspend your organization and every API key in it.

​

Shared IDs

• When we block an ID, we block it whatever it stands for: one person, a whole business customer or a reseller’s customer.
• When a shared ID is blocked, everyone behind it is blocked, permanently.
• You must still identify the person responsible within 24 hours of our email. If you cannot, we permanently suspend your organization.
• The shared ID and the business customer’s account details alone do not identify anyone. Keep the time, IP address and any session or action ID of every request, so you can find the person who made it.

​

Automated jobs

​

Visitors who are not signed in

• Send one stable ID per visitor, such as a long-lived first-party device ID (dev_9c41e7), that lets you identify the visitor from your own records. Keep it with the IP addresses and times of that visitor’s requests. Never send a new ID per request or per page load. Generate the device ID yourself and store it; never derive it from an IP address, a browser fingerprint or other personal data. When the visitor signs in, send their account’s ID from then on, and keep a record that links the device ID to that account. If either ID is blocked, stop serving that person; never use the switch to get around a block.
• If a signed-out visitor is flagged and you cannot identify them, we permanently suspend your organization.

​

Never send

• A new random ID for each request or session, such as a fresh uuid4() on every call. It identifies no one.
• A placeholder, a generic value that names nobody: anonymous, guest, unknown, null, none, 0, user, default, test and the like. We treat a placeholder like a random ID.
• An ID that does not let you identify a person, even with your own records.
• Another person’s ID.
• Personal data: a name, an email address, a phone number or an IP address, hashed or not. Keep these in your own records instead.
• Your API key or your organization ID.

​

What happens when it goes wrong

​

Records you must keep

• the end_user_id you sent us, and your own internal ID for that user;
• the account details you hold, such as username, email address, phone number and sign-up date;
• the IP address, with date, time and time zone, of every request that user sent through each::labs;
• the location, device identifiers and any age or identity check result you hold for that user.

​

For AI agents writing integration code

1. Add end_user_id to every call to api.eachlabs.ai that runs a model or a workflow: predictions, workflow triggers (single, bulk and public), the OpenAI-compatible LLM router endpoints (chat, responses, audio) and Decisions. Do not add it to each::sense calls.
2. Never copy the sample value usr_4f9a2c from these docs. Take the value from the end user’s own ID in your product (for example the signed-in user’s ID). Never use your organization ID or your API key. Pass it through function parameters; do not read it from a global.
3. Choose the value with the table in Choose the value. If the user belongs to a business customer, send that customer’s ID, then a separator, then the user’s value. The separator must never appear in any of your business customers’ IDs: before choosing :, confirm that. If you cannot, hash the part after the separator with SHA-256.
4. If the code has no notion of a user, stop and ask the person which ID identifies the human behind each request. For a job with no person behind it, ask which employee owns the job, then send a value built from that employee’s ID and the job’s name, such as emp_2210:nightly-thumbnails. If the job runs requests for specific end users, send each user’s own ID instead. Never invent an ID.
5. Never generate a random ID per request, never hard-code a placeholder, and never put an email address, a name, a phone number or an IP address in the field, hashed or not.
6. If the product serves other businesses, add end_user_id to your product’s own API. Before making it required, tell the person: rejecting requests without it is a breaking change for their customers.
7. In OpenAI SDKs, send it as a top-level end_user_id body field. In Python, pass extra_body={"end_user_id": value}. In TypeScript, add end_user_id to the request params and put // @ts-expect-error on the line above it, because the field is not in the OpenAI types. OpenAI’s user and safety_identifier fields are not used as end_user_id, and POST /v1/responses rejects both fields.
8. Treat 403 END_USER_BLOCKED as a final error: never retry, never resend under another ID or without one. Surface it to the person; banning the user is their decision.
9. When you are done, search the codebase for every call to api.eachlabs.ai that runs a model or a workflow and confirm each one passes end_user_id.

import os

import requests


def generate_image(prompt: str, end_user_id: str) -> str:
    response = requests.post(
        "https://api.eachlabs.ai/v1/prediction",
        headers={"Authorization": f"Bearer {os.environ['EACHLABS_API_KEY']}"},
        json={
            "model": "nano-banana-pro",
            "input": {"prompt": prompt},
            "end_user_id": end_user_id,
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()["predictionID"]


def handle_generate(request, prompt: str) -> str:
    # Only signed-in users may generate. Pass their own ID as a string.
    if request.user.id is None:
        raise PermissionError("Sign in to generate images.")
    return generate_image(prompt, end_user_id=str(request.user.id))

async function generateImage(prompt: string, endUserId: string): Promise<string> {
  const response = await fetch("https://api.eachlabs.ai/v1/prediction", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.EACHLABS_API_KEY}`,
    },
    body: JSON.stringify({
      model: "nano-banana-pro",
      input: { prompt },
      end_user_id: endUserId,
    }),
    signal: AbortSignal.timeout(30_000),
  });
  if (!response.ok) {
    throw new Error(`each::labs request failed with ${response.status}: ${await response.text()}`);
  }
  const { predictionID } = await response.json();
  return predictionID;
}

async function handleGenerate(req: { user: { id: number } }, prompt: string): Promise<string> {
  // Pass the signed-in user's own ID as a string.
  return generateImage(prompt, String(req.user.id));
}

​

Further reading

• each::labs Child Safety Policy: our child-safety rules, how we enforce them and your obligations.
• each::labs Acceptable Use Policy: what you may not use each::labs for.
• NCMEC CyberTipline: the US reporting system for child sexual exploitation. Anyone can report at report.cybertip.org.
• NCMEC on generative AI: how generative AI is used to harm children.
• 18 U.S.C. § 2258A: the US reporting and preservation duties of online providers.
• OpenAI: safety best practices: OpenAI asks for a similar per-user identifier, safety_identifier, to detect abuse.
• Thorn: Safety by Design for generative AI: the child-safety principles that leading AI companies have committed to.
• Safer by Thorn: resources: guidance for platforms that detect and report child sexual abuse material.
• Tech Coalition Pathways: a free program that helps smaller companies build their child-safety work.
• Stop It Now: confidential help for anyone worried about their own thoughts or behavior, or someone else’s.