Swagger API documentation with Bearer Token authentication
API Documentation (1.0)
Auth
Auth endpoints handle user authentication and session management. They support login (email/password), registration, password reset (request and reset), email verification (verify and resend), logout, company selection, and user profile retrieval (/me). Authentication uses Bearer tokens and integrates with the multi-tenant company system, allowing users to access multiple companies. The auth system manages user sessions, email verification tokens, password reset tokens, and company access. Auth endpoints temporarily disable scope violation tracking during authentication operations to allow unauthenticated access to login/register endpoints.
Feeds
Feed endpoints serve XML/RSS feeds for job boards and external integrations. Feeds enable syndication of Records (typically vacancies) to job aggregators and external systems. Feeds are generated from XML files stored on the server and can be accessed publicly or with authentication. The feed system enables companies to publish their job listings to external job boards, aggregators, and recruitment platforms, expanding the reach of their job postings and enabling automated job distribution.
Sync
Sync configurations define automated data synchronization mappings between CaraerObjects. A Sync specifies how property values from source Records should be mapped to target Records, enabling automated data flow between different object types. Syncs use Mappings that define source and target properties, allowing data to be copied, transformed, or synchronized when source Records are created or updated. Syncs are used for data integration, automation workflows, and keeping related data in sync across the platform. They enable scenarios like automatically creating a Company Record when a User Record is created, or syncing Candidate data to an external system. Syncs support complex mapping rules and can trigger on various Record events.
Webhooks
Webhooks are event-driven HTTP callbacks that notify external systems when Records are created, updated, deleted, archived, restored, or when specific events occur (e.g., FormSubmissionEvent, PropertyValueChanged, RelationCreated). Webhooks support filtering to only trigger on Records matching specific criteria, retry logic with configurable backoff, relation inclusion for sending related Record data, and multiple payload formats (LEGACY, structured). Webhooks enable integrations with external systems, automation workflows, and real-time data synchronization. They can be associated with Apps for third-party integrations and support secret-based authentication. Webhooks are essential for building event-driven architectures and connecting Caraer with external tools and services.
Relations
Relations define typed connections between CaraerObjects, enabling graph-like data modeling. A Relation specifies how Records of one Object can connect to Records of another Object (e.g., "Candidate applies to Vacancy", "Company has Employees"). Relations create directed or bidirectional relationships between Records, allowing navigation and querying of related data. Relations support cardinality, directionality, and can be used in filtering, sorting, and querying Records. They enable complex data structures where Records reference each other, creating a graph database model on top of the object-oriented schema. Relations are essential for modeling real-world relationships between entities and enable powerful querying capabilities across connected Records.
Forms
Forms are dynamic data collection interfaces associated with CaraerObjects. They use a grid-based layout system with FormItems (GridItems) arranged in rows and columns that can render various field types based on Property definitions. Forms support multi-step wizards, lead scoring configurations, styling options (standard, underline, plain), and form submissions that create Records. Forms enable public-facing data collection (e.g., job applications, contact forms, candidate registrations) and can be embedded in Webpages. Forms validate input against Property validation rules and can include nested forms (inner forms) for complex data structures. Form submissions trigger FormSubmissionEvents and can create Relations between Records. Forms are essential for converting external user input into structured Records in the platform.
File Management
File endpoints manage file uploads and downloads using S3-compatible storage. Files are used for attachments, images, documents, and media in Records and Webpages. Files support property format constraints (when used with file-type Properties) and access control through scopes. The file system provides pre-signed URLs for secure, time-limited access to files, supports bulk uploads, and can list files associated with specific Records. Files are stored with unique keys and can be deleted when no longer needed. The file system enables rich content management, allowing Records and Webpages to include images, documents, and other media assets.
Users
Users represent authenticated individuals in the system. Users belong to one or more Companies and can switch between them. Users can be members of Teams, have roles (SUPER_ADMIN, DEVELOPER, etc.) and scopes that determine their permissions. Users can have associated Records (if the User trait is enabled on an object), enabling user profiles and authentication. Each User has access configurations (HAS_ACCESS_TO) per company that define scopes, filters, and permissions. Users can request additional permissions, reset their permissions to match their team's permissions, and manage their own profile data. The User system enables authentication, authorization, and user management across the multi-tenant platform.
Filter
SavedFilters are reusable filter configurations that users can save and share. They encapsulate complex filter criteria for Records, enabling quick access to filtered data views without re-entering filter conditions. SavedFilters improve UX by allowing users to bookmark common queries (e.g., "Active Candidates", "Open Vacancies", "My Applications") and share them with team members. Filters can be soft-deleted and restored, and they support the same filter capabilities as Views but are stored separately for quick access. SavedFilters enable consistent data access patterns across teams and reduce the time needed to access frequently-used filtered views.
Views
Views are saved configurations for displaying Records that define filters, sorting, visible properties (show), grouping, calculations, row heights, and display traits (table, flow). Views enable users to create custom perspectives on data (e.g., "My Active Candidates", "High Priority Vacancies", "Recent Applications"). Each View belongs to a CaraerObject and specifies how Records of that Object should be displayed. Views can be shared with other users, set as default views, and include query strings for search functionality. Views support different traits like Table (tabular display), Flow (kanban-style workflow), and can include calculations for aggregated data. Views improve UX by allowing users to bookmark common queries and share them with team members, ensuring consistent data presentation across the platform.
Partner
Partner endpoints manage partner relationships and integrations. Partners may have special access, integrations, or white-label configurations. Partner endpoints enable reseller functionality, allowing partners to create companies, copy databases, and manage their partner relationships. Partners can have reseller relationships with companies, enabling multi-level partner structures. The partner system supports database copying for white-label deployments and partner-specific company management.
Teams
Teams are user groups within a Company that enable role-based access control and collaboration. Teams can be assigned to Records, enabling team-based workflows and permissions. Teams help organize users and manage access to data and features. Team members inherit team permissions and scopes, allowing administrators to manage access at the team level rather than individually. Teams support member management (add/remove members), permission reset (applying team permissions to members), and can be used in filtering and access control. Teams enable collaborative workflows where groups of users work together on Records, with shared permissions and access patterns.
Records
Records are actual data instances belonging to a CaraerObject. They contain property values that conform to the object's schema defined by Properties. Records support dynamic relationships via Relations, enabling graph-like data modeling where Records can reference and navigate to related Records. Records can be filtered, sorted, paginated, and displayed in various views (table, flow, page, preview). They support morphing (association with multiple objects), soft deletion with restore capability, and property parsing for formatted display. Records are the core data entities that users create, update, and manage. Each Record has a UUID, belongs to a primary Object, can have morph objects (making it visible in multiple object contexts), and maintains createdAt/updatedAt timestamps. Records enable the platform's dynamic, content-driven data management.
Traits
Traits are behavioral features that can be added to CaraerObjects to extend their functionality without modifying the core schema. Common traits include Flow (kanban-style workflow management), Table (tabular data display with sorting and filtering), Page (enables Records to have public-facing Webpages), and User (enables user authentication and user profile Records). Traits are composable - an Object can have multiple traits enabled simultaneously. Traits extend object functionality by adding specific behaviors, UI components, and capabilities. For example, the Flow trait adds workflow state management, the Table trait adds list view capabilities, and the Page trait enables CMS functionality. Traits enable flexible feature composition where objects can be customized with different capabilities based on business needs.
ConfigController
Config endpoints provide frontend configuration including branding, feature flags, and platform settings. Configuration is company-specific and enables customization of the platform UI and behavior. The config endpoint returns settings that the frontend needs to render the application correctly, including company branding, available features, and platform-specific configurations. Configuration values are determined at runtime based on the authenticated user's selected company and their access permissions.
Developer
Dev endpoints provide developer utilities for testing, debugging, and development. These endpoints may include test data generation, error simulation, database query execution, progress tracking via Server-Sent Events (SSE), and development tools. Dev endpoints are typically restricted to users with DEVELOPER role and are intended for development and testing purposes only. They enable developers to test functionality, debug issues, and perform administrative tasks during development.
Request
Streams progress updates to the client using Server-Sent Events (SSE). The client must provide a 'count' parameter in the request body to indicate the number of events to emit. Each event includes a progress percentage, and the stream completes after emitting the specified number of events.
- Mock serverhttps://developer.caraer.com/_mock/apis/api/v2/dev/stream-test
- Productionhttps://v2.api.caraer.com/api/v2/dev/stream-test
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://developer.caraer.com/_mock/apis/api/v2/dev/stream-test \
-H 'Authorization: Bearer <YOUR_Opaque_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"property1": "string",
"property2": "string"
}'- Mock serverhttps://developer.caraer.com/_mock/apis/api/v2/dev/db-status
- Productionhttps://v2.api.caraer.com/api/v2/dev/db-status
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
https://developer.caraer.com/_mock/apis/api/v2/dev/db-status \
-H 'Authorization: Bearer <YOUR_Opaque_HERE>'- Mock serverhttps://developer.caraer.com/_mock/apis/api/v2/dev/
- Productionhttps://v2.api.caraer.com/api/v2/dev/
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
https://developer.caraer.com/_mock/apis/api/v2/dev/ \
-H 'Authorization: Bearer <YOUR_Opaque_HERE>'Webpages
Webpages are CMS pages associated with Records that enable public-facing content. They support dynamic content layouts using PageContent structures, preview and production environments, scheduled publishing (publishAt/unpublishAt), SEO metadata (title, excerpt, slug, image), custom CSS and JavaScript, and sidebar previews. Webpages are used to create career sites, landing pages, job detail pages, and other public-facing content. They integrate with Forms for data collection and Previews for displaying related Records. Webpages can be published/unpublished, support environment-specific content (preview vs production), and maintain publication timestamps. The Webpage system enables dynamic, data-driven public websites where content is managed through Records and automatically rendered as HTML pages.
Property
Properties define the schema and field definitions for CaraerObjects. A Property specifies the data type (string, number, date, boolean, etc.), format (text, email, select, multi-select, linked, file, etc.), validation rules (required, unique, character limits, etc.), and display options (label, description, icon, groups). Properties determine what data Records can store, how it's validated, how it's displayed in forms and views, and how it can be searched. Each Property belongs to a CaraerObject and defines one field in that object's schema. Properties support various formats including linked properties (relationships to other Records), file uploads, rich text, and custom option lists. Properties are immutable once created to maintain data integrity, and they can be organized into groups for better UX. The Property system enables dynamic, schema-on-read data modeling where object structures can be customized per company without code changes.
Applications
Apps are third-party integrations and extensions that extend Caraer functionality. They can provide additional features, connect to external services, include Webhooks for event handling, and offer custom UI components through AppBars. Apps enable the platform ecosystem where companies can integrate with their existing tools and workflows. Apps can be public (available to all companies) or private (company-specific), have pricing models, descriptions, and settings schemas. Apps can include Webhooks with rate limiting and secret-based authentication. The App system enables extensibility and integration capabilities, allowing the platform to connect with external systems and provide additional functionality beyond the core platform features.
Modules
Modules are reusable page content components (PageContent) that can be shared across Webpages. They enable content reusability, template systems, and consistent UI components. Modules can be public (shared across all companies in the platform) or private (company-specific). Public modules are managed by developers and provide common content templates, while private modules allow companies to create their own reusable content blocks. Modules use the same PageContent structure as Webpages, enabling complex layouts with sections, rows, columns, and various content types. Modules improve content management efficiency by allowing content creators to reuse common components across multiple pages, ensuring consistency and reducing duplication.
Company
Companies represent multi-tenant organizations in Caraer. Each company has its own isolated database, users, objects, Records, and data. Companies enable SaaS multi-tenancy where each organization's data is completely isolated from others. Companies have settings (branding, configuration), subdomains for custom URLs, and can be customized with their own Objects, Properties, Forms, and Webpages. Users belong to one or more companies and can switch between them. Companies maintain their own access control, scopes, and permissions. The Company system enables the platform to serve multiple organizations while maintaining strict data isolation and allowing each company to customize the platform to their needs.
Objects
CaraerObjects are schema definitions for dynamic domain entities (e.g., "Candidate", "Vacancy", "Company"). They define the structure and behavior of Records through Properties (field definitions), Relations (connections to other objects), Views (display configurations), and Traits (behavioral features like Flow, Table, Webpage, User). Objects enable a flexible, schema-on-read data model where entities can be customized per company without code changes. Each Object has a name (lowercase identifier), label (display name), plural form, description, icon, and can be organized into groups. Objects can have traits that add specific behaviors: Flow enables kanban-style workflows, Table provides tabular data views, Webpage allows Records to have public-facing pages, and User enables authentication and user profiles. Objects are the foundation of the platform's dynamic data modeling system.