Awee

Custom Integrations

How businesses can onboard onto the Awee platform and build dynamic software components that expose themselves as UI, REST APIs, or repeatable automations.

Every business has automation needs that don't fit neatly into off-the-shelf software. Awee is built for exactly this gap - a platform where a business can define its own data shapes, build its own workflows, and surface everything through whatever interface its team actually uses.


The integration model

Onboarding a new business onto Awee means three things: understanding what data they manage, understanding how that data moves, and deciding how people interact with it. Everything else is configuration and components.

The platform provides:

  • A data layer - schema-enforced tables and records, scoped per entity or tenant
  • An automation engine - workflows composed from built-in and custom components
  • A UI layer - configurable views over the data, with actions wired to automations
  • An API layer - every component and workflow is automatically addressable as a REST endpoint

A business does not need to build all four from scratch. They start with the data that matters to them, define the automations that act on it, and pick the interface that fits their team.


Onboarding a new business

Discovery: map the data and the processes. The first step is understanding what records the business manages and how they flow. What triggers work? What decisions get made? What external systems are involved? This produces a data schema and a process map - the inputs to everything that follows.

Define the data model. Tables, fields, and relationships are defined using the engine's data platform components. Field types cover text, numbers, dates, selects, relations, files, and computed values. The schema is version-controlled and can evolve without data loss.

Build the workflows. Core business automations are written as engine workflows - YAML configs that chain built-in and custom components. Common patterns (approval chains, AI-assisted processing, external API calls, notification dispatch) are built once and reused.

Configure the UI. Views are assembled from UI components backed by the live data. Teams see filtered tables, forms, and dashboards configured for their role - no code required to adjust what columns appear, what actions are available, or what data is visible.

Expose as API if needed. Any workflow or component can be published as a REST endpoint. External systems - existing software the business already uses - can trigger automations, push records, or query data over standard HTTP.

Iterate and extend. New components can be added at any time. A business that starts with a simple approval workflow can later add AI-assisted classification, external system sync, or a customer-facing portal - all built on the same foundation.


Dynamic software components

The core primitive is the component - a discrete unit of logic that takes typed inputs and produces typed outputs. Components can be built by anyone and registered with the engine. Once registered, they behave identically to built-in components: they can be used in any workflow, called via REST, or exposed in the UI.

A component can surface in three ways:

A component that renders a view - a table, a form, a dashboard widget, an action button. UI components are backed by live data and wired to automation workflows. A review form that submits a decision, a table that shows records filtered by status, a dashboard that aggregates metrics - all implemented as UI components.

component: ui:table
vars:
  schema: content_translations
  filter: "{{ status | eq 'pending_review' }}"
  columns: [title, source_language, target_language, assigned_reviewer]
  actions:
    - label: Approve
      workflow: translation:approve
    - label: Reject
      workflow: translation:reject

Any workflow with an input_schema can be published as a REST endpoint. Incoming requests are validated against the schema, the workflow runs, and the response is the workflow's output map.

id: invoice:create
input_schema:
  entity_id: string
  amount: number
  currency: string
  due_date: string
outputs:
  invoice_id: "{{ create_record.id }}"
  status: "{{ create_record.status }}"

Once published, POST /api/invoice:create is available to any external system - an existing ERP, a customer portal, a third-party service.

A component registered as an automation step can be composed into any workflow. It receives inputs from prior steps, does its work, and passes outputs forward.

- name: classify
  component: finance:categorise_transaction
  vars:
    description: "{{ transaction.description }}"
    amount: "{{ transaction.amount }}"
    entity_id: "{{ transaction.entity_id }}"

- name: post
  component: ledger:post
  vars:
    account: "{{ classify.account_code }}"
    amount: "{{ transaction.amount }}"
    entity_id: "{{ transaction.entity_id }}"

Managing components over time

Components are versioned. A business can deploy a new version of a component without breaking existing workflows - old versions continue to run until they are explicitly migrated. This makes it safe to evolve custom components as business requirements change.

Component management covers:

  • Registration - name, version, input schema, output schema, and the implementation
  • Testing - components can be tested in isolation with fixture inputs before being used in production workflows
  • Monitoring - every execution is traced; errors, latency, and cost are visible per component in the accounting layer
  • Deprecation - old versions can be flagged for migration; workflows referencing deprecated components surface in a migration queue

Custom components follow the same cost accounting model as built-in components. If a custom component makes AI calls or external API requests, those costs are tracked automatically and attributed to the workflow run that triggered them.


Common integration patterns

Inbound data sync

Pull records from an external system on a schedule or via webhook, normalise them into the Awee data layer, and trigger downstream workflows automatically.

Outbound API calls

Push records or events to external systems - accounting software, CRMs, ERPs, communication tools - as a step in any workflow, with dynamic auth and payload assembly.

Human-in-the-loop

Surface decisions that require human judgment as tasks in the UI queue. The workflow pauses until a reviewer acts; their decision routes the next step.

AI-assisted processing

Add an AI step to any workflow - classification, extraction, translation, summarisation, generation. Results feed directly into downstream steps or human review queues.

Scheduled operations

Run any workflow on a cron schedule - daily reports, nightly reconciliation, weekly digest emails - with full tracing and cost tracking on every run.

Event-driven composition

Emit named events from one workflow to trigger others. Decouple complex processes without building a custom event bus - the engine handles routing.


What a custom integration looks like end-to-end

A mid-sized agency manages projects, invoices, and contractor payments across multiple clients. They want to automate the gap between project delivery and payment collection - currently a manual process involving spreadsheets, email, and a separate accounting tool.

With Awee:

  1. A project completion event - fired from their existing project management tool via webhook - triggers an invoice:generate workflow.
  2. The workflow pulls project data, calculates billable hours, and generates an invoice record in the Awee data layer.
  3. A finance team member reviews the invoice in the Airtable-style UI and approves or adjusts it.
  4. On approval, the engine pushes the invoice to their accounting software via a custom xero:invoice:create component and sends the client a notification.
  5. Payment status is polled daily via a scheduled workflow. When payment is received, a contractor:payment:schedule workflow runs to queue the contractor payout.
  6. The finance dashboard shows open invoices, overdue payments, and cash position across all clients - updated automatically from the same data layer.

Every step is a component. Every component is reusable. The agency's custom components - project data extraction, Xero integration, contractor payout logic - are assets that can be extended, versioned, and reused across future workflows.


Getting started

If you have a business process that involves structured data, external systems, human decisions, or AI - it can be modelled as an Awee integration. The starting point is always the same: map the data, map the flow, and identify the decisions.

From there, the engine, the UI, and the API layer provide the infrastructure. You provide the business logic.

How is this guide?

On this page