PHPackages                             carlosgude/integration-engine - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [HTTP & Networking](/categories/http)
4. /
5. carlosgude/integration-engine

ActiveSymfony-bundle[HTTP & Networking](/categories/http)

carlosgude/integration-engine
=============================

Connect external APIs to Symfony through configurable adapters, without writing repetitive clients.

v3.0.0(3w ago)918MITPHPPHP >=8.2CI failing

Since May 31Pushed 3w ago1 watchersCompare

[ Source](https://github.com/CarlosGude/integrationEngine)[ Packagist](https://packagist.org/packages/carlosgude/integration-engine)[ Docs](https://github.com/CarlosGude/integrationEngine)[ RSS](/packages/carlosgude-integration-engine/feed)WikiDiscussions main Synced 1w ago

READMEChangelog (10)Dependencies (11)Versions (42)Used By (0)

IntegrationEngine
=================

[](#integrationengine)

**Website:** [integrationengine.dev](https://integrationengine.dev)

External integrations tend to rot in Symfony projects.

Every API becomes a different shape, a different structure, a different way of thinking. After a few months, you no longer have integrations. You have a zoo.

IntegrationEngine forces every integration to look the same.

---

Core idea
---------

[](#core-idea)

An integration is not a client.

It is a collection of predictable endpoints.

Every endpoint has exactly two responsibilities:

- Request (what goes in)
- Response (what comes out)

Nothing else is allowed to sprawl.

---

What this solves
----------------

[](#what-this-solves)

IntegrationEngine removes:

- Inconsistent API clients across services
- Ad-hoc HTTP logic scattered in services
- Repeated mapping boilerplate per endpoint
- "How does this API work again?" moments
- Integration archaeology after months

---

Quick usage
-----------

[](#quick-usage)

```
$response = $dummyRestApi->getEmployee(123); // typed Response DTO
$employee = $dummyRestApiGateway->find(123); // domain object, via the ACL Gateway
```

No HTTP clients. No request builders. No mappers. Just integrations.

See it wired into a real Symfony app — REST, GraphQL, and dynamic OAuth2 — in the [demo repository](https://github.com/CarlosGude/integrationEngine-use-example).

---

Installation
------------

[](#installation)

```
composer require carlosgude/integration-engine
```

Requires PHP 8.2+ and Symfony 7.0+. The bundle registers itself automatically via Symfony Flex.

---

Scaffolding
-----------

[](#scaffolding)

Generate a full integration skeleton with the built-in command:

```
# New integration + first action
php bin/console make:integration MyApi GetEmployee

# Add an action to an existing integration
php bin/console make:integration MyApi CreateEmployee
```

The command is interactive — it asks for base URL, client type, HTTP method, and path. It generates the `Action`, `Mapper`, `Response`, and updates the YAML action map.

---

Structure
---------

[](#structure)

Each integration follows the same predictable directory layout:

```
src/Infrastructure/Integrations/{Name}/
├── {Name}Integration.php          ← facade + NAME constant
├── {Name}.yaml                    ← action map (path, method, class)
└── {ActionName}/
    ├── Request/
    │   └── {ActionName}Action.php
    └── Response/
        ├── {ActionName}Response.php
        └── {ActionName}Mapper.php

```

Shared DTOs used by multiple actions go in a `Dto/` directory at the integration root.

If you know one integration, you know them all.

---

Configuration
-------------

[](#configuration)

Register each integration in `config/packages/integration_engine.yaml`:

```
integration_engine:
    integrations:
        my_api:
            base_url: 'https://api.example.com'
            config_path: '%kernel.project_dir%/src/Infrastructure/Integrations/MyApi/MyApi.yaml'
            headers:              # optional — sent with every request
                X-Api-Version: '2'
            cache_service: ~      # optional — defaults to cache.app
            client: rest          # optional — "rest" (default) or "graphql"
            client_service: ~     # optional — fully custom ClientInterface, overrides client
```

The action map YAML maps each action name to its class, method, and path:

```
GetEmployee:
    action: App\Infrastructure\Integrations\MyApi\GetEmployee\Request\GetEmployeeAction
    method: GET
    path: /employees/{id}

CreateEmployee:
    action: App\Infrastructure\Integrations\MyApi\CreateEmployee\Request\CreateEmployeeAction
    method: POST
    path: /employees
```

---

Sending a request
-----------------

[](#sending-a-request)

The engine is accessed via `IntegrationRegistry`. Always wrap registry calls in an integration facade — never call the registry directly from a controller or service:

```
use IntegrationEngine\Core\Batch\EngineRequest;
use IntegrationEngine\Core\Contract\Action\DefaultActionContext;
use IntegrationEngine\Core\IntegrationEngine;
use IntegrationEngine\Core\Registry\IntegrationName;
use IntegrationEngine\Core\Registry\IntegrationRegistry;

// 1. Facade (infrastructure layer) — returns typed Response DTOs, nothing else
final class MyApiIntegration implements IntegrationName
{
    public const string NAME = 'my_api';

    private IntegrationEngine $engine;

    public function __construct(IntegrationRegistry $registry)
    {
        $this->engine = $registry->get(self::NAME);
    }

    // Single request
    public function getEmployee(int $id): GetEmployeeResponse
    {
        $response = $this->engine->send(
            actionName: GetEmployeeAction::getName(),
            context: DefaultActionContext::create(['id' => $id]),
        );
        \assert($response instanceof GetEmployeeResponse);
        return $response;
    }

    // Parallel fan-out — N requests at once, results keyed like the input
    public function getManyEmployees(array $ids): array
    {
        $requests = [];
        foreach ($ids as $id) {
            $requests[$id] = EngineRequest::create(
                GetEmployeeAction::getName(),
                DefaultActionContext::create(['id' => $id]),
            );
        }

        $results = $this->engine->sendMany($requests); // BatchResultCollection

        if ($results->hasFailures()) {
            throw array_values($results->errors())[0];
        }

        return $results->responses(); // array
    }
}

// 2. Gateway (the Anti-Corruption Layer) — the only class that knows both
// the integration's DTOs and the domain model
final class MyApiGateway
{
    public function __construct(private MyApiIntegration $integration) {}

    public function find(int $id): Employee // domain object
    {
        $dto = $this->integration->getEmployee($id)->employee;
        return new Employee(id: $dto->id, name: $dto->name);
    }

    /** @return list */
    public function findMany(int ...$ids): array
    {
        $employees = [];
        foreach ($this->integration->getManyEmployees($ids) as $id => $response) {
            $employees[$id] = new Employee(id: $response->employee->id, name: $response->employee->name);
        }
        return $employees;
    }
}
```

Controllers and other application code depend only on the Gateway — never on the integration facade or its DTOs directly. Without this boundary, a breaking change in the external API propagates straight into your domain model; with it, adapting to an API change means updating one Gateway class.

`sendMany()` returns a `BatchResultCollection` — one result per key, successes and failures independent. Real concurrency requires the client to implement `BatchClientInterface`: the default `rest` client does, `graphql` does not. For GraphQL or SOAP with real concurrency, use `client_service:` and implement `BatchClientInterface`yourself. See [DOCUMENTATION.md](DOCUMENTATION.md) → *Batch / Parallel Requests* for the full API, failure-handling patterns, and concurrency details.

---

Path parameters and query strings
---------------------------------

[](#path-parameters-and-query-strings)

Path segment parameters (`{id}`) are resolved automatically from context:

```
GetEmployee:
    path: /employees/{id}
```

```
DefaultActionContext::create(['id' => 42]) // → /employees/42
```

For **optional** query string filters, implement `PathResolvableContextInterface` in a custom context — path logic lives in the context, the action stays declarative:

```
use IntegrationEngine\Core\Contract\PathResolvableContextInterface;

final readonly class FilterEmployeesContext implements PathResolvableContextInterface
{
    private function __construct(private array $filters) {}

    public static function create(array $data): self { return new self($data); }
    public function toArray(): array { return $this->filters; }

    public function resolvePath(string $path): ?string
    {
        $allowed = ['status', 'department', 'page'];
        $params  = array_filter(
            array_intersect_key($this->filters, array_flip($allowed)),
            static fn(mixed $v): bool => '' !== (string) $v,
        );
        // null → fall back to the default {placeholder} resolver
        return empty($params) ? null : $path . '?' . http_build_query($params);
    }
}
```

For **required** query string params, declare them as placeholders directly in the YAML path:

```
FilterByStatus:
    path: /employees?status={status}  # throws if 'status' is missing from context
```

---

Authorization
-------------

[](#authorization)

### Static (API key, bearer token, basic auth)

[](#static-api-key-bearer-token-basic-auth)

Declare in the action entry in `{Name}.yaml`:

```
GetOrders:
    action: App\...\GetOrdersAction
    method: GET
    path: /orders
    authorization:
        type: bearer
        token: '%env(MY_API_TOKEN)%'
```

Supported types: `bearer`, `basic` (`username` + `password`), `api_key` (`header` + `token`, optional `prefix`).

### Dynamic (OAuth 2.0, session tokens)

[](#dynamic-oauth-20-session-tokens)

The engine calls a token action automatically, caches the result, and injects it as static auth on all protected actions. No manual token management needed:

```
FetchToken:
    action: App\...\FetchTokenAction
    method: POST
    path: /oauth/token

GetOrders:
    action: App\...\GetOrdersAction
    method: GET
    path: /orders
    authorization:
        type: dynamic
        action: FetchToken      # calls this action to obtain the token
        token_field: access_token
        ttl: 3600
        header: Authorization   # optional — header carrying the token
        prefix: Bearer          # optional — defaults to Bearer for Authorization, none for custom headers
```

The token action is a regular action and requires its own `Action`, `Mapper`, and `Response`. The response must expose the token field via `toArray()`.

If a cached token is rejected with HTTP 401 before its TTL expires (revoked or expired server-side), the engine evicts it from the cache and retries the request **once** with a freshly fetched token. No manual token invalidation needed.

> **Cache scope.** The default cache backend is `cache.app`, which is process-local under PHP-FPM. Each worker fetches its own token on first warm-up. For APIs with strict rate limits on the token endpoint, configure `cache_service` with a shared Redis pool.

---

HTTP adapters
-------------

[](#http-adapters)

Two adapters are included:

TypeKeyUse case`SymfonyHttpClientAdapter``rest`Standard REST APIs`GraphQLClientAdapter``graphql`GraphQL endpointsSelect one with the `client` key — no `client_service` needed for either built-in:

```
integration_engine:
    integrations:
        rick_and_morty:
            base_url: 'https://rickandmortyapi.com/graphql'
            client: graphql       # switches to GraphQLClientAdapter; no method/path per action
```

For GraphQL actions, the body must implement `GraphQLBodyInterface`:

```
use IntegrationEngine\Core\Contract\GraphQLBodyInterface;

final class GetUserBody implements GraphQLBodyInterface
{
    public function getQuery(): string  { return 'query { user(id: $id) { name } }'; }
    public function getVariables(): array { return ['id' => $this->id]; }
    public function toArray(): array    { return ['query' => $this->getQuery(), 'variables' => $this->getVariables()]; }
    public static function create(array $data): self { return new self((int) $data['id']); }
}
```

### Custom adapters

[](#custom-adapters)

Implement `ClientAdapterInterface` and tag the service — the bundle discovers it automatically:

```
use IntegrationEngine\Core\Contract\AbstractAction;
use IntegrationEngine\Core\Contract\ClientAdapterInterface;

final class SoapClientAdapter implements ClientAdapterInterface
{
    public static function getClientType(): string { return 'soap'; }
    public static function requiresPath(): bool    { return false; }
    public static function requiresMethod(): bool  { return false; }
    public function send(AbstractAction $action, ...): array { ... }
}
```

```
# services.yaml
App\Infrastructure\Http\SoapClientAdapter:
    tags:
        - { name: integration_engine.client_adapter }
```

Project adapters override bundle built-ins when registered with the same `getClientType()`.

### Custom middleware

[](#custom-middleware)

Every outgoing request passes through an ordered middleware pipeline before reaching the HTTP adapter. You can inject your own layers — rate limiting, retry logic, circuit breaking, custom logging — by extending `AbstractClientMiddleware` and tagging the service:

```
use IntegrationEngine\Core\Contract\Client\AbstractClientMiddleware;
use IntegrationEngine\Core\Contract\Action\AbstractAction;
use IntegrationEngine\Core\Contract\Action\ActionContextInterface;
use IntegrationEngine\Core\Contract\Client\RequestHeadersInterface;

final class RateLimitMiddleware extends AbstractClientMiddleware
{
    public function process(
        AbstractAction $action,
        ?ActionContextInterface $context,
        ?RequestHeadersInterface $headers,
        callable $next,
    ): array {
        $this->limiter->consume(); // your rate-limiting logic
        return $next($action, $context, $headers);
    }
}
```

```
# services.yaml
App\Infrastructure\Http\RateLimitMiddleware:
    tags:
        - { name: integration_engine.middleware }

# integration_engine.yaml
integration_engine:
    integrations:
        my_api:
            middlewares:
                - App\Infrastructure\Http\RateLimitMiddleware  # outermost first
```

The `middlewares:` key under each integration controls injection order — first entry is outermost (runs before the HTTP call). The bundle guarantees `CachingMiddleware` is always prepended as the outermost layer and `TracingMiddleware` (debug only) is always the innermost built-in; your middlewares sit between them.

Override `processMany()` as well if you need batch-aware behaviour (e.g. splitting a batch by rate-limit bucket). The default passthrough from `AbstractClientMiddleware` is correct for most cases.

### Dynamic base URL per request

[](#dynamic-base-url-per-request)

Some integrations don't have one fixed base URL — for example, an installable app where each store/customer lives on its own domain. For those cases, pass `baseUrl` to `send()`:

```
$engine->send('get_orders', context: $context, baseUrl: $tenant->domain());
```

It's optional and fully backward-compatible: omit it and the engine keeps using the `base_url` from configuration, exactly as before. Both built-in adapters (`SymfonyHttpClientAdapter`, `GraphQLClientAdapter`) support it; a custom client ignores it silently unless it implements `DynamicBaseUrlClientInterface`. The bundle does not resolve or persist that URL — that's the calling code's responsibility.

### Symfony Profiler integration

[](#symfony-profiler-integration)

In `dev`/`test`, every outgoing call made through a configured integration shows up automatically in the Symfony Toolbar — integration, action, method, path, duration, and status, with no configuration needed:

```
IntegrationEngine          3 calls · 184.2 ms
  GetEmployee   GET  /api/v1/employee/42      62.1 ms   200
  GetArtist     GET  /v1/artists/4Z8W...       91.0 ms   200
  FetchToken    POST /api/token                31.1 ms   200

```

It's purely additive: in `prod` the `TracingMiddleware` is not wired, so there is zero profiling overhead.

---

Further reading
---------------

[](#further-reading)

- [`DOCUMENTATION.md`](./DOCUMENTATION.md) — deeper guide: engine pipeline, all configuration options, and links to per-topic references.
- [`ARCHITECTURE.md`](./ARCHITECTURE.md) — design decisions: why actions are stateless, the mapper invariant, cache behaviour under PHP-FPM, and the DTO/domain boundary.
- [`TESTING.md`](./TESTING.md) — test philosophy, suite structure, and what each test protects.
- [`CONTRIBUTING.md`](./CONTRIBUTING.md) — setup, code quality tools, and how to run the test suite.
- [`docs/`](./docs/) — per-topic references: actions, authorization, batch requests, clients, context and path resolution, mappers and responses.
- [`integrationEngine-use-example`](https://github.com/CarlosGude/integrationEngine-use-example) — full working demo app showing the bundle wired into a real Symfony project.

---

When NOT to use it
------------------

[](#when-not-to-use-it)

- You only have 1–2 simple API calls
- You need full low-level HTTP control everywhere
- You don't want enforced structure in your codebase

###  Health Score

46

—

FairBetter than 92% of packages

Maintenance94

Actively maintained with recent releases

Popularity14

Limited adoption so far

Community9

Small or concentrated contributor base

Maturity58

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 99.5% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~0 days

Total

41

Last Release

27d ago

Major Versions

v1.27.1 → v2.0.02026-06-12

v2.3.1 → v3.0.02026-06-27

### Community

Maintainers

![](https://www.gravatar.com/avatar/39797f7748bab759e2eaf839dde619da9f925d6adae6c56e3acd25d87d2112f9?d=identicon)[Carlgud](/maintainers/Carlgud)

---

Top Contributors

[![CarlosGude](https://avatars.githubusercontent.com/u/3743766?v=4)](https://github.com/CarlosGude "CarlosGude (219 commits)")[![aikido-autofix[bot]](https://avatars.githubusercontent.com/in/268977?v=4)](https://github.com/aikido-autofix[bot] "aikido-autofix[bot] (1 commits)")

---

Tags

api-clientbundledddhexagonal-architecturehttp-clientintegrationphpphp8symfonysymfony-bundleapisymfonybundleadapterintegrationhexagonalengine

###  Code Quality

TestsPHPUnit

Static AnalysisPHPStan

Code StylePHP CS Fixer

Type Coverage Yes

### Embed Badge

![Health badge](/badges/carlosgude-integration-engine/health.svg)

```
[![Health](https://phpackages.com/badges/carlosgude-integration-engine/health.svg)](https://phpackages.com/packages/carlosgude-integration-engine)
```

###  Alternatives

[shopware/core

Shopware platform is the core for all Shopware ecommerce products.

585.6M600](/packages/shopware-core)[sulu/sulu

Core framework that implements the functionality of the Sulu content management system

1.3k1.4M215](/packages/sulu-sulu)[friendsoftypo3/content-blocks

TYPO3 CMS Content Blocks - Content Types API | Define reusable components via YAML

103519.9k57](/packages/friendsoftypo3-content-blocks)[bitrix24/b24phpsdk

An official PHP library for the Bitrix24 REST API

10244.2k5](/packages/bitrix24-b24phpsdk)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)