Skip to main content
Entities represent the people and companies your organization works with in Syntage. Use an entity ID to request data, start extractions, manage identifiers, assign entity tags, and review events for that person or company. An entity can be created with a name, type, optional RFC, optional identifiers, and optional datasources to start extracting. If required information is missing, Syntage returns an onboarding URL that can be used to collect the missing information from the entity.

​
When Syntage returns an onboardingUrl

The POST /entities response includes onboardingUrl only when Syntage still needs input from the entity to complete setup. The most common trigger is an omitted rfc. If your request already provides a valid rfc (and any other information Syntage needs to resolve the entity), the response omits onboardingUrl or returns it as empty because no onboarding step is required.
Returned onboarding URLs do not expire.

​
How Entities Are Used

  1. Create or retrieve an entity.
  2. Store the entity ID returned by Syntage.
  3. Use the entity ID when requesting datasource records, creating extractions, listing events, assigning tags, or adding identifiers.
  4. If Syntage returns an onboardingUrl, send the entity to that URL or embed the onboarding experience in your own site.
The entity ID is stable across datasources. A single entity can be connected to SAT credentials, RPC data, RUG data, Buró de Crédito reports, Infonavit data, and more.

​
Entity IDs

Use the entity ID in new integrations:
Some older endpoints also accept RFC-based URLs for backwards compatibility. New endpoints and features are only added under entity-based URLs. For endpoint details, see Entities API Reference.

​
Identifiers

Identifiers store country-specific values that can be used by datasources and product workflows. Mexico currently supports: Identifiers may be supplied when creating an entity or added later with the entity identifiers endpoint.

​
Personal favorites

Favorites let each user keep a personal selection of entities within their organization. Other users, including administrators, have their own selections. Favoriting an entity does not change its tags or grant access to it; an entity you can no longer access is excluded from your results.

​
Favorites API

Send POST /entities/favorites to add one or more favorites or DELETE /entities/favorites to remove them. Both methods accept the same JSON body with entity IRIs:
Supply 1–100 entity IRIs. Repeated IRIs are processed once. Each batch is atomic: if any entity is missing or inaccessible, no favorites change. Successful additions and removals return 204 No Content without a response body. Repeating an add or removal is safe; adding an existing favorite preserves its timestamps. GET entity list and item responses include isFavorite for the authenticated user by default. If you select response fields with properties[], include properties[]=isFavorite to receive it; create and update responses do not include this field. Use GET /entities?isFavorite=true for favorites or ?isFavorite=false for other accessible entities. The authenticated user and organization determine whose favorites are changed; neither can be selected in the request. Read-only users can manage their favorites with JWT authentication. Their existing API-key restriction still applies.

​
Entity Tags

Entity tags are organization-defined labels for grouping and filtering entities. They are useful when your integration needs to treat a set of entities the same way. Common use cases include: Create entity tags first, then assign them to an entity by updating the entity’s tags collection. When updating an entity’s tags, send the complete list of entity tag IRIs the entity should have. The submitted list replaces the previous assignments.