Apideck APIs

16 APIs356 Endpoints9 Categories

API Catalog(5 of 16)

Connector API

The Apideck Connector API is the meta-API that describes the integrations Apideck Unify supports. It exposes the list of connectors (Salesforce, HubSpot, Xero, Greenhouse, Slack, etc.), the unified APIs each connector implements (CRM, ATS, Accounting, and so on), the documentation pages, and the schema and example payload for any resource. Builders use it to render in-app integration catalogues, check coverage before they prompt a customer to authorise, and inspect the schema for an operation at runtime.

10 endpoints

Ecosystem API

The Apideck Ecosystem API exposes a read-only catalog of integration listings, categories, collections, and products that power Apideck-hosted integration marketplaces. Applications query this API to render an in-product 'integrations' directory without maintaining their own metadata store, including descriptions, logos, and category groupings for each listing. All twelve endpoints are GET operations scoped under a parent ecosystem ID, with listings filterable by category or collection. It is designed for embedded marketplace UIs rather than for connecting to or executing calls against the underlying integrations.

12 endpoints

Issue Tracking API

The Apideck Issue Tracking API is a unified interface across Jira, Linear, GitHub Issues, GitLab Issues, Asana, and Trello. A single set of 15 endpoints covers tickets, comments, users, tags, and the project-like 'collections' that group them, eliminating the need to maintain a separate integration per tracker. All ticket and comment operations support full CRUD, while users and tags are read-only — they reflect data managed in the underlying tool. Tickets are addressed by both collection_id (the project) and ticket_id, mirroring how trackers scope issues to a project or repository.

15 endpoints

Proxy API

The Apideck Proxy API forwards arbitrary HTTP requests to a connector's underlying API while reusing the OAuth token and configuration that Apideck has already negotiated with the end user. Five endpoints — GET, POST, PUT, PATCH, DELETE — all on the single /proxy path expose the full HTTP surface, with the target service identified by Apideck headers and the path passed through to the upstream provider. It exists as an escape hatch when a Unified API does not cover a feature the agent or product needs to call directly. Authentication uses the Apideck Authorization header plus x-apideck-app-id; the consumer ID identifies which connection the request is forwarded over.

5 endpoints

Webhook API

The Apideck Webhook API manages webhook subscriptions and delivery for events emitted by Apideck Unified APIs. Ten endpoints cover subscription CRUD, manual webhook execution against a specific service, callback resolution paths used by connectors that push events back, and event log retrieval for debugging. A subscription is identified by ID and scoped to a service, with execute and resolve endpoints allowing replay or on-demand delivery. Authentication uses the Apideck Authorization header alongside x-apideck-app-id and x-apideck-consumer-id.

10 endpoints

Connect Your Agent

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.