One gateway

Every app Era can use goes through one gateway. It doesn't matter whether you call a tool from the desktop chat, a workflow step, the SDK or an MCP client: the same connection, the same permission check and the same error messages apply.

Three ways Era reaches an app

When an app is reachable more than one way, it is still one entry in Apps (/apps). The coverage row at the top of that page shows the totals: apps, actions (tools), triggers, and what you have connected.

Who may run what

The same rule applies to every tool:

1. Every app stands for an Era module.

   • CRMs → Sales
   • Payment and accounting apps → Finance
   • HR apps → People
   • Help desks and customer messaging → Inbox
   • Mailing and social tools → Campaigns
   • Databases → Data
   • Analytics → Reports
   • Anything else (docs, developer tools, search…) → Apps
   • If that module is switched off in your workspace, the app falls under Apps.

2. A step that only reads needs view access to that module. A step that changes something needs edit access. A step counts as read-only only when it is:

   • a GET request, or
   • named as a read (get, list, search…) without a changing verb.

   Anything else counts as a change.

3. Who "the person" is depends on where the step runs:

   • App or desktop: the signed-in member.
   • Workflow: its Run as person (whoever deployed its trigger, otherwise its owner). Never a system user.
   • API key or OAuth token: the key's scopes ∩ the member's current role.

4. Which connection is used: a connection of that app that the person may use — their own, one shared with them, or the company's.

   • Era never falls back to another app.
   • If nothing is connected, the call fails with "App is not connected".

Example: a sales member can use HubSpot through the company's shared connection. They cannot read Stripe payments with it, because Stripe needs Finance access.

Triggers

An app's triggers appear as workflow trigger blocks. They come in two kinds:

• Instant (webhook): the app calls Era. When the app signs its deliveries, Era verifies the signature with the secret you set before it starts the workflow.
• Scheduled check (polling): Era asks the app at a sensible interval, for example RSS, Gmail, Outlook and IMAP.

Use it from code

import { createEra } from '@getera/sdk'
const era = createEra({ apiKey: process.env.ERA_API_KEY })

const { data, coverage } = await era.apps.list({ q: 'crm' })        // the catalogue
const tools = await era.apps.tools('hubspot')                       // tools + argument schemas
await era.apps.hubspot.hubspot_get_contacts({ limit: 10 })          // one tool by name
await era.apps.call('wikipedia', 'wikipedia_search', { query: 'Istanbul' })

HTTP endpoints:

• GET /api/v1/apps lists the apps.
• GET /api/v1/apps/{app} returns one app with its tools and triggers.
• GET /api/v1/apps/{app}/tools lists the app's tools.
• POST /api/v1/apps/{app}/tools/{tool} runs a tool. Send { "arguments": { … }, "connection": "auto" | "mine" | "workspace" | "<id>" }.

Over MCP (Claude Code, Codex, Cursor), the gateway is three tools instead of thousands:

• apps__search finds an app.
• apps__tools lists its tools.
• apps__call runs one.

In a workflow, use the Era connected app step (pick the app, name the tool, give the arguments) or the app's own block.

More apps through Composio or Pipedream (optional)

To reach apps Era doesn't have natively, an owner can add a provider key under Apps → Secrets:

• Composio: COMPOSIO_API_KEY
• Pipedream Connect: PIPEDREAM_CLIENT_ID, PIPEDREAM_CLIENT_SECRET and PIPEDREAM_PROJECT_ID. Optionally set PIPEDREAM_ENVIRONMENT.

Those apps are addressed as composio:<toolkit> or pipedream:<app> everywhere an app id goes. Searching works like this: GET /api/v1/apps?provider=composio&q=….

They follow the same permission rule as every other app. Each member connects their own account at the provider; only a manager can add a company account.

This is off by default: Era ships no provider key.