Skip to main content
Use these relationships when combining API operations in an integration.

​
Platform and Student

A Platform is the professional’s branded space. Its Courses, learning paths, Services, Community, Students, Offers, Orders and integration settings belong to that Platform. Authenticated API requests use the current account and its Platform as context. Student is the API’s account entity for both Students and Administrators. The role field distinguishes student and administrator accounts.

​
Course, Module, Content and Level

A Course contains ordered Modules; each Module contains ordered Content. The current customer-facing content types are:
  • Video lessons, with a video, notes and optional lesson resources. Student progress records playback progress.
  • Quizzes, with questions, a passing score and Student attempts. An attempt records the questions and passing score used when it was taken.
A Course may also have Course Levels. A Module with no Level association belongs to the common curriculum for Course owners. A Level can unlock selected Modules for a Student who also has access to the parent Course. A Student can own more than one Level, and the accessible curriculum is the union of common Modules and Modules unlocked by those Levels.
Changing a Level’s associated Modules can change access for existing Students.

​
Course sales page

Each Course has a sales page that presents it to prospective Students. It combines Course information with benefits, page blocks, featured reviews, FAQs and instructor profiles. Its purchase options depend on the Course’s Offers and availability. The sales page is part of the Course. Editing it and publishing the Course are separate actions. Page blocks and instructor profiles can be reused across pages; editing a shared record updates the pages connected to it.

​
Learning paths

A learning path, represented by Path in the API, organizes Courses into a recommended sequence. A Course can belong to one learning path at a time. Courses retain their own curriculum, Offers and access grants. Prices and purchases belong to the Courses and Offers; to sell the Courses in a learning path together, use an Offer containing them. Path progress is derived from the Student’s progress in its Courses.

​
Services

A Service presents professional work such as consulting or coaching. Its page can collect a request in Creatora or direct the person to an external URL. A Service can also be included in an Offer. The Service page’s displayed price is presentation information; purchasing happens through the Offer. A contact request and a purchase are different records, and purchasing a Service does not automatically start its delivery.

​
Community

The Community is a Platform-wide area for link and text posts, comments, votes and saved posts. Access is independent of ownership of a particular Course. When enabled, its content is publicly readable. Publishing, commenting, voting and saving require a registered account. Community discussions and discussions attached to a Course’s lessons are separate contexts.

​
Offer, Order and access

An Offer describes what someone can obtain. Every Course has an automatic base Offer. A custom Offer can include Courses, optional Levels for those Courses, Services and custom items. An Order records a commercial attempt or a sale registered in Creatora. A successful Order can produce an acquisition, which records what was obtained, and Course or Level grants, which determine current learning access. A direct free Offer claim can create an acquisition without an Order. An Administrator can also grant Course access directly without creating an Order. Recording a sale creates commercial history. Granting access directly gives learning access without recording a purchase. A Course Level grant requires access to its parent Course; removing the final Course-access source removes dependent Level grants. Use the complete API schema to look up operations, inputs, and response fields. Recipes combine operations into reporting and Course workflows.

​
Integrations

An integration connects the Platform to an external provider. Its installed instance holds the provider-specific configuration, such as credentials, list IDs and mappings between Creatora data and provider tags or attributes. Available integrations include Mailchimp, Mailjet, Brevo, Google Analytics, Meta Pixel and Mixpanel. When an integration is active, its stored configuration is available through Creatora’s API. You can reuse that data in custom integrations, including credentials for calls to the external provider. The available fields depend on the provider: API keys, identifiers and configuration mappings are different kinds of integration data. For example, an Administrator can retrieve the API key of the Platform’s installed Mailchimp integration through platform.integration.mailchimp.instance.apiKey. Use the current SDL to find each provider’s fields and access requirements. Each integration’s isActive field indicates whether it is installed; instance is null when it is not installed. Use the Authentication guide to authenticate as an Administrator. Calls to the external provider use that provider’s credentials and API, separately from Creatora’s GraphQL requests. Keep provider credentials in your integration’s server-side configuration.