Overview
The automatic person creation endpoint allows you to create persons by providing minimal information (tax ID and country). The system automatically:
- Fetches person data from official registries
- Enriches the person with additional information
- Executes integrations (checks and enrichments) automatically
This is ideal for KYC (Know Your Customer) processes where you want to onboard customers with complete information automatically.
Endpoint
POST http://api.gu1.ai/entities/automatic
Authentication
Requires a valid API key in the Authorization header:
Authorization: Bearer YOUR_API_KEY
Request Body
Tax identification number of the person (e.g., CPF for Brazil, CURP for Mexico, CUIT for Argentina)
ISO 3166-1 alpha-2 country code (e.g., “BR”, “MX”, “AR”, “CL”)
Your unique identifier for this person (optional, will be auto-generated if not provided)
Mark this person as a client/customer for tracking purposes
UUID of the risk matrix to execute rules from automatically
Skip automatic rules execution after person creation
status
string
default:"under_review"
Initial status for the person
Depth of relationship extraction (0-5). Controls how many levels of relationships to automatically fetch and create.
0: No relationships (only main entity)
1: Direct relationships only
2: Relationships + their relationships
3-5: Additional levels (use with caution - can create many entities)
Configure automatic execution of integrations for the main person entity. See Provider Codes Reference for available codes.Type: object (optional)Properties:
executeAllActiveEnrichments (boolean, optional, default: false) - Execute all active enrichment integrations
executeAllActiveChecks (boolean, optional, default: false) - Execute all active check integrations
enrichments (array, optional, default: []) - Array of specific enrichment provider codes to execute
checks (array, optional, default: []) - Array of specific check provider codes to execute
{
executeAllActiveEnrichments?: boolean; // default: false
executeAllActiveChecks?: boolean; // default: false
enrichments?: ValidProviderCodesEnum[]; // default: []
checks?: ValidProviderCodesEnum[]; // default: []
}
Example:{
"executeAllActiveEnrichments": false,
"enrichments": ["br_bdc_basic_data_enrichment"],
"checks": ["pep_check", "sanctions_check"]
}
autoExecuteIntegrationsShareholders
Configure automatic execution of integrations for discovered relationships. Useful when using depth > 0. See Provider Codes Reference for available codes.Type: object (optional)Properties:
executeAllActiveEnrichments (boolean, optional, default: false) - Execute all active enrichments on related entities
executeAllActiveChecks (boolean, optional, default: false) - Execute all active checks on related entities
enrichments (object, optional) - Specific enrichments by entity type
company (array, default: []) - Enrichments for company relationships
person (array, default: []) - Enrichments for person relationships
checks (object, optional) - Specific checks by entity type
company (array, default: []) - Checks for company relationships
person (array, default: []) - Checks for person relationships
{
executeAllActiveEnrichments?: boolean;
executeAllActiveChecks?: boolean;
enrichments?: {
company?: ValidProviderCodesEnum[];
person?: ValidProviderCodesEnum[];
};
checks?: {
company?: ValidProviderCodesEnum[];
person?: ValidProviderCodesEnum[];
};
}
Example:{
"enrichments": {
"person": ["br_cpfcnpj_complete_person_enrichment"],
"company": ["br_cpfcnpj_complete_company_enrichment"]
}
}
Required Enrichment Codes by Country
When using specific enrichment codes (not executeAllActiveEnrichments: true), certain enrichments are mandatory for the automatic creation to work. Without them, the system cannot fetch basic person data from official registries and the request will fail.
Brazil (BR)
| Scenario | Required Enrichment Code(s) | Description |
|---|
| Main entity | br_bdc_basic_data_enrichment | Fetches person data via BDC/CPF (full name, date of birth, address, etc.) |
Relationships (depth > 0) | br_bdc_related_companies_enrichment AND br_bdc_related_persons_enrichment | Both required in autoExecuteIntegrations.enrichments. Fetches companies and persons related to the individual |
The relationship enrichments must be included in the main entity’s autoExecuteIntegrations.enrichments array (not in autoExecuteIntegrationsShareholders), because the system needs to run them on the main person to discover the relationships. The autoExecuteIntegrationsShareholders field controls what enrichments to run on each related entity after they are created.
Argentina (AR)
| Scenario | Required Enrichment Code | Description |
|---|
| Main entity | ar_nosis_extended_verification_enrichment | Fetches person data from Nosis |
Argentina does not support automatic relationship creation yet. The depth parameter must be 0.
Optional - Custom attributes as key-value pairs for the created entity.Applied only to the main entity (the person created), not to relationships/shareholders. Useful for business segments, tags, internal IDs, or any metadata you want to associate at creation time.Structure: object with string keys and values of any type (string, number, boolean, array, etc.).Example:{
"businessSegments": ["retail", "fintech"],
"source": "onboarding_web",
"tags": ["vip", "high_volume"]
}
Response
Indicates if the person was created successfully
Complete information about the creation:
entity (object) - The person created with all data
summary (object) - Creation summary
errors (object, optional) - Details of any errors
Result of rules execution (only present when rules ran, e.g. when skipRulesExecution is false and riskMatrixId is provided), or null. When present, includes:
- success (boolean) - Whether rules executed successfully
- rulesTriggered (number) - Number of rules that were triggered
- alerts (array) - Alerts generated by rules
- riskScore (number) - Final calculated risk score
- decision (string) - Final decision (APPROVE, REJECT, HOLD, REVIEW_REQUIRED)
- rulesExecutionSummary (object) - Present when rules ran. See below for structure.
At the root of the response (same as transactions API). Same value as rulesResult.rulesExecutionSummary. Only present when rules ran (e.g. skipRulesExecution is false and risk matrix was executed). Summary of which rules matched (hit) vs did not match (no hit), executed actions, and total score. Omitted when rules did not run. See Rules Execution Summary for the full structure and a complete example.
- rulesHit (array) - Rules whose conditions were met. Each item: name, description, score, priority, category, status (e.g.
active, shadow), conditions (array of { field, value, operator? }), actions (alerts, suggestion, status, assignedUser).
- rulesNoHit (array) - Rules that were evaluated but conditions were not met. Same structure as rulesHit (includes configured actions, not executed).
- actionsExecuted (object) - Aggregated executed actions across all rules that hit: alerts, suggestion (
BLOCK | SUSPEND | FLAG, highest weight), status (entity status applied, if any), assignedUser ({ userId }, if any), customKeys (array of strings, optional) — custom action keys from matched rules; for integrations/workflows.
- totalScore (number) - Sum of score of all rules that hit and are not in
shadow status.
Examples
Create Person with All Active Integrations
curl -X POST http://api.gu1.ai/entities/automatic \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"taxId": "123.456.789-00",
"country": "BR",
"type": "person",
"isClient": true,
"autoExecuteIntegrations": {
"executeAllActiveEnrichments": true,
"executeAllActiveChecks": true
}
}'
Create Person with Specific Integrations
curl -X POST http://api.gu1.ai/entities/automatic \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"taxId": "123.456.789-00",
"country": "BR",
"type": "person",
"externalId": "customer_12345",
"autoExecuteIntegrations": {
"enrichments": ["br_bdc_basic_data_enrichment"]
}
}'
Response Example
{
"success": true,
"data": {
"entity": {
"id": "person_uuid",
"organizationId": "org_uuid",
"type": "person",
"name": "João Silva",
"taxId": "12345678900",
"countryCode": "BR",
"status": "under_review",
"entityData": {
"person": {
"firstName": "João",
"lastName": "Silva",
"dateOfBirth": "1985-05-15",
"nationality": "BR"
}
},
"createdAt": "2024-12-23T10:30:00.000Z",
"updatedAt": "2024-12-23T10:30:00.000Z"
},
"summary": {
"entitiesCreated": 1,
"relationshipsCreated": 0,
"errorsCount": 0
}
},
"rulesResult": null
}
Error Responses
400 Bad Request - Invalid Tax ID
{
"success": false,
"error": "Invalid CPF format for Brazil"
}
404 Not Found - Person Not Found in Registry
{
"success": false,
"error": "Entity not found in official registry",
"details": {
"taxId": "123.456.789-00",
"country": "BR",
"registry": "Receita Federal"
}
}
409 Conflict - Person Already Exists
{
"success": false,
"error": "Entity with this tax ID already exists",
"details": {
"existingEntityId": "uuid",
"taxId": "123.456.789-00"
}
}
Best Practices
- Error handling: Always check the
success field in the response
- Rate limiting: Be mindful of rate limits when creating multiple persons
- Integration selection: Choose specific integrations for better control over cost and performance
Next Steps