Customer Management

Manage people and companies from one API

Create, query and manage your customer records from the API and the dashboard.

Create free account View documentation
People and companies
A full history per customer
Free test environment
The customer record

Every check on a customer, in a single record.

Every check is recorded on the file with its reference and date. The full history comes back in one pass, with the evidence ready for an audit.

One record
per customer, person or company
Reference and date
on every check
Full history
in one pass

Two person types, one API

Individual

Name, surnames, sex and date of birth. The second surname, the CURP and the RFC are optional. The checks run on the record, from CURP validation through to identity verification.

Company

A company record opens with the legal name and the trade name. The RFC is validated with the SAT using the record’s RFC; judicial records and sanctions screening search both names in a single query.

What the record holds

Nearly every field is optional. The record opens with the data available and the rest is added later. Some fields hold the identity data the checks match against; others, the context your team records.

Customer reference

The record identifier. You run every check with it and pull the full history with it.

Example cus_lzk9m4ab3f9c2d1e

API field: id · string
Person type

Indicates whether the record belongs to a person or a company. It sets the onboarding data and the available checks.

Example physical

API field: type · string
First name

The person’s given name or, when the record is a company, its trade name.

Example María Fernanda

API field: name · string
SurnamesMay be empty

As they appear on the official ID. The second surname is optional.

Example García Hernández

API field: last_name / mothers_last_name
Registered company nameMay be empty

The name the company was incorporated under. A company record opens with it.

Example Tech, S.A. de C.V.

API field: legal_name · string | null
Date of birthMay be empty

Captured in three separate fields: day, month and year.

Example 15 · 03 · 1990

API field: birth_day / birth_month / birth_year
SexMay be empty

In the format Mexican official registries use.

Example M

API field: gender · string | null
Place of birthMay be empty

Country, Mexico by default, plus the Mexican state when the birth was in Mexico. A country other than Mexico marks the customer as foreign.

Example MX · Ciudad de México

API field: birth_country / birth_place
CURPMay be empty

Mexico’s national population key. Optional at onboarding, it can be added later. It enables the checks that depend on it.

Example GAHM900315MDFRRR05

API field: curp · string | null
RFCMay be empty

The tax ID of the person or the company. The SAT confirmation takes it from the record.

Example GAHM900315AB1

API field: rfc · string | null
Customer emailMay be empty

The email lookup reads it from the record.

Example [email protected]

API field: datameta.email · string | null
Customer phoneMay be empty

The phone lookup takes it from the record.

Example +52 55 1234 5678

API field: datameta.phone · string | null
Company, address and contextMay be empty

The record stores company, job title, city, state, country, address and nationality.

Example Grupo Torres · Procurement

API field: datameta · object
CURP matchMay be empty

The result of the latest RENAPO validation, with the official document when it was downloaded. It indicates whether the captured data matched the registry.

API field: curp_validation · object | null
Your own identifierMay be empty

The identifier the customer already has in your system. It is stored on the record and search accepts it just like the reference.

Example crm-48213

API field: custom_id · string | null
Risk labelMay be empty

The tag your team assigns to the record: low, medium or high.

Example medium

API field: risk · string | null

How it works

Step 1

Open the record

Send the customer data. The record opens and returns its reference.

Step 2

Run the checks

Every check runs against that reference and its result is recorded on the same record. The RENAPO CURP match is stored there and identity verification reuses it when the result was successful.

Step 3

Read the history

The record returns the full profile and the list of every check run on that person.

What you can run on a record

Every run joins the customer history with its reference and date. Under each tool sits what it needs in order to run.

CURP at RENAPO

A RENAPO query plus a match against the data you already captured.

with the CURP on the record

RFC at the SAT

Confirms with the SAT that the tax ID is registered, and to whom.

with the RFC on the record

Voter ID and roll check

Reads the voter ID card and confirms it is current on the electoral roll.

front and back

Identity verification

The customer’s selfie matched against the document, with a liveness test.

24-hour link

Lists and sanctions

Hits on public lists, with the detail behind each one.

name and date of birth

Judicial records

Court files with the court itself and the parties involved.

searches by name

Phone

Validity, country, carrier and line type.

with the phone on the record

Email

Which platforms that address is registered on.

with the email on the record

Risk score

Pulls the signals from what you already ran into a single number.

0-to-100 scale

A customer history, check by check

Each check appears with the tool, the result, the date and its reference.

Customer history
María Fernanda García Hernández
cus_lzk9m4ab3f9c2d1eProduction
  • CURP validation12 Mar · 09:41

    Data matches RENAPO

    Reference req_9c4b2ad17e

  • Lists and sanctions12 Mar · 09:42

    No matches found

    Reference req_1f7e0b93cc

  • Voter ID and roll12 Mar · 09:44

    Card is current

    Reference req_5b30e7a2f1

  • Identity verification12 Mar · 10:02

    Selfie matched to document

    Reference req_77c1d4e6a9

Each line also keeps the full response from the source queried.

Search on any detail

By name, by email, by the customer reference or by the identifier your team already uses. Results come back paginated.

Two separate environments

The same structure runs in test and in production, on separate data. The test environment is free.

Record updates

A new detail, such as a CURP or a phone number, is added to the record that already exists.

Two catalogues, one file

The record stores your system’s identifier next to the Singula reference. Both point at the same file.

How teams use it day to day

What your team defines and what the record keeps.

Your review calendar

Checks run when your team fires them, at onboarding or at each contract renewal. Your team defines who gets reviewed and how often; every run is recorded on the same record.

Consent and privacy

They stay inside your own flow, under the rules your legal team already agreed on, identity verification included. The record keeps what was queried and on what date.

Label and score

The record keeps two values: the tag your team assigns and the 0-to-100 score calculated from the checks already run.

Foreign nationals and companies

A foreign customer onboards like any other, with a country of birth on the record. People and companies share the same catalogue and the same search.

API

Everything runs through the API.

Every operation on this page runs as an API call. The full field-by-field reference is in the documentation.

customers-create.sh
curl -X POST https://api.singula.mx/customer \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "name": "Maria", "last_name": "Garcia",
        "mothers_last_name": "Rodriguez", "gender": "M",
        "birth_day": "15", "birth_month": "03",
        "birth_year": "1990", "env": "production" }'

→ {
    "data": {
      "id": "cus_lzk9m4ab3f9c2d1e",
      "type": "physical",
      "name": "Maria",
      "last_name": "Garcia",
      "env": "production"
    }
  }

Frequently asked questions

Yes. The record stores your identifier next to the Singula reference and search takes either one. The reference goes straight to the record; anything else searches name and email.

Yes. CURP and RFC are optional. Open the record with a name and a date of birth. Once they are added, the checks that depend on them become available.

Yes, as long as your own organisation ran it on that CURP and it came back successful. When you open the record you point at the reference of that earlier validation and it joins the customer history.

Every check run on that person, with the tool, the outcome, the date and its reference. The record returns the history together with the profile.

In the test environment, which runs on isolated data at no cost. You run onboarding and every check there. When you switch to production, test data stays in that environment.

The history keeps the full response from every source queried.

Open the first record

Create the account, try onboarding and the checks in the free test environment, and move to production once your team signs off.

Create free account