Short answer: How Aamu.app AI uses OpenAPI descriptions and user-owned credentials to read data from external services and turn the result into Aamu Docs and Database rows.

Some of the information you need for work does not live in Aamu. It may be in your X account, GitHub, Slack, Jira, Linear, CRM, helpdesk, or another service that your team uses every day. The goal is useful context, not giving AI a suitcase full of integrations and hoping it remembers where it put the socks.

Aamu.app AI can now work with those services through their APIs. The important distinction is that this is not about using an external provider as the AI model. It is about letting AI use a service that you have authorised, then bringing the useful result back into your Aamu workspace.

OpenAPI describes what a service can do

An API key by itself is only a credential. It may let a request authenticate, but it does not tell AI which operations exist, which parameters are required, or what the response means.

That is where OpenAPI helps. An OpenAPI document describes an API's operations, paths, parameters, authentication schemes, and response formats in a machine-readable form. Aamu can use that description as a capability map for the external service.

This means Aamu does not need a built-in connector for every possible service. You provide an OpenAPI description and a credential with the required permissions. The available actions then depend on the operations described by that document and on what the credential is allowed to access.

Add a service in Third-Party API keys

External service credentials belong in Settings → Third-Party API keys. For each service, you can add:

  • a service identifier and a label that helps you recognise it,

  • the API key or token,

  • an optional base URL, and

  • the service's OpenAPI 3.0 or 3.1 document in JSON or YAML.

The OpenAPI document explains the API. It does not grant access by itself. The key or token remains the thing that authorises the request, and its scopes still limit what can be returned.

Aamu stores the credential in the user's own settings and does not put the secret into the AI prompt. The server resolves the credential only when it needs to make the external request.

From a request to an API call

When you use Launch AI or mention @ai, the request follows the same AI path as other Aamu actions:

  1. The intent router recognises that the request concerns an external service.

  2. It compares the request with the operations available in your configured OpenAPI descriptions.

  3. AI selects an operation and fills in the required parameters from your request and conversation context.

  4. Aamu checks the request, applies your credential on the server, and calls the external API.

  5. The result is returned to the conversation or used to create something in Aamu.

The intent router is useful here because the user should not have to name an endpoint or know the API's internal terminology. “Find my open support tickets” is a work request. The OpenAPI operation is the implementation detail that Aamu resolves behind it.

Example: turn X direct messages into an Aamu Database

Imagine that you want to collect customer conversations from X for follow-up work. You could ask Launch AI:

Fetch my X direct messages from the last month and create an Aamu Database with one row per conversation. Include the sender, date, message text, and a link if the API provides one.

If the configured OpenAPI document contains a compatible direct-message operation and your token has the required permission, Aamu can call that operation, interpret the response, and create a structured Database.

This is a good Database use case because each conversation becomes a row that you can filter, sort, assign, enrich, and process further. The same request could also create a Doc with a short summary of the recurring topics.

The exact result depends on the service API. Aamu does not assume that every X account, token, or OpenAPI document exposes private messages. The API description and the permissions granted to your credential define the real boundary.

Example: Stripe customers and payment intents

A concrete example is importing Stripe customers and payment intents into a native Aamu Database. The important part is that Aamu can preserve the relationship between the records instead of creating two unrelated tables.

You

Can you get customers and their payment intents from Stripe and create a database from it?

If you can create references in the tables that would be event better.

AI

Yes. Please select the Stripe resources for:

GetCustomers — /v1/customers

GetPaymentIntents — /v1/payment_intents

I’ll use them to create a native Aamu database with separate Customers and PaymentIntents tables, linked through the customer ID reference.

You

GetCustomers — /v1/customers

GetPaymentIntents — /v1/payment_intents

AI

Your native Aamu database “stripe import” has been created successfully with:

Customers table

PaymentIntents table

1 reference linking payment intents to their customers

In this example, the customer value in a PaymentIntent is matched with the corresponding customer record and stored as an Aamu reference. Payment intents without a customer value, or without a matching customer in the imported data, remain unlinked. The result is a relational Aamu Database that can be filtered and extended like any other Aamu data.

Examples from other services

The same pattern can be useful in many kinds of work:

  • GitHub: collect open issues, pull requests, reviews, or release information into a Database. Ask AI to create a release-readiness Doc from the selected results.

  • Slack: retrieve messages from a permitted channel and turn a discussion into a decision log or a follow-up Database. This depends on the operations and scopes exposed by the configured Slack API.

  • Jira or Linear: import issues, sprint items, or recently completed work into a Database, then generate a planning Doc grouped by project, owner, or status.

  • CRM or helpdesk: bring contacts, companies, tickets, or conversation history into Aamu so that customer context can be reviewed and followed up in one place.

  • Analytics and monitoring: retrieve incidents, metrics, or service events and create an incident brief in a Doc or a triage table in a Database.

These are examples of possible workflows, not a promise that every service is already connected out of the box. The service must expose a usable OpenAPI description, and the credential must be allowed to perform the requested read.

When should the result be a Doc or a Database?

Use a Doc when the useful output is a narrative: a summary of a thread, a release brief, a customer context page, or a list of decisions and next steps.

Use a Database when the response contains repeatable records: one row per message thread, ticket, issue, contact, incident, or event. Database rows make the imported data easier to filter, update, assign, and use in later workflows.

AI can also combine the two: import the source records into a Database and create a Doc that explains the important patterns found in them.

Designed for user-owned access

Third-party API access is deliberately tied to the user who adds the credential. Aamu should not turn one person's private service account into a shared team connection by accident.

The OpenAPI document is a description of capabilities, not an instruction to give AI unrestricted access. In the initial implementation, Aamu focuses on read operations such as GET and HEAD. API-key headers and query parameters, bearer tokens, and OAuth2-style access tokens can be described by the configured API definition.

Write operations can have real side effects: sending a message, changing a ticket, deleting a record, or publishing content. Those actions need a more explicit confirmation and safety model before they should be treated like ordinary retrieval.

Getting started

  1. Open Settings → Third-Party API keys.

  2. Add the service's API key or access token.

  3. Paste the service's OpenAPI 3.0 or 3.1 JSON/YAML description.

  4. Open Launch AI or write an @ai request that describes the outcome you want.

Start with a read-only request and inspect the returned data before asking AI to create a Doc or import rows. If the service requires a particular account scope, workspace ID, or date range, include that context in the request.

Related Aamu AI workflows

AI commands in Aamu.app: turning comments into workspace actions explains how Launch AI and @ai can already route requests to actions inside Aamu.

Company Brain in Aamu.app covers permission-aware retrieval from the Aamu workspace itself.

A practical guide to Aamu.app Databases shows how structured rows can become a working part of the workspace.

With third-party APIs, Aamu.app AI can connect those ideas: understand a request, use an API that you have authorised, and turn external information into work that stays useful inside Aamu.

Frequently asked questions

What is Using third-party APIs through Aamu.app AI?

How Aamu.app AI uses OpenAPI descriptions and user-owned credentials to read data from external services and turn the result into Aamu Docs and Database rows.

Who is Using third-party APIs through Aamu.app AI for?

This guide is intended for developers and technical teams.

What does this guide explain?

It explains the main concepts, setup, and practical workflow for using third-party apis through aamu.app ai.

Related articles