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:rejectAny 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:
- A project completion event - fired from their existing project management tool via webhook - triggers an
invoice:generateworkflow. - The workflow pulls project data, calculates billable hours, and generates an invoice record in the Awee data layer.
- A finance team member reviews the invoice in the Airtable-style UI and approves or adjusts it.
- On approval, the engine pushes the invoice to their accounting software via a custom
xero:invoice:createcomponent and sends the client a notification. - Payment status is polled daily via a scheduled workflow. When payment is received, a
contractor:payment:scheduleworkflow runs to queue the contractor payout. - 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?