Use case
We use n8n to orchestrate customer notifications. One step requires sending an SMS via Openapi when a form is submitted. Currently we call a custom PHP endpoint that wraps the SDK, but it feels like unnecessary infrastructure.
Current architecture
n8n Webhook → HTTP Request → PHP endpoint → Openapi SDK → SMS API
The PHP endpoint looks like:
<?php
require 'vendor/autoload.php';
use Openapi\Client;
$body = json_decode(file_get_contents('php://input'), true);
$client = new Client(getenv('OPENAPI_TOKEN'));
echo $client->post('https://sms.openapi.com/send', [
'to' => $body['phone'],
'text' => $body['message'],
]);
Ideal state
A Docker-composable PHP microservice (or even a standalone FrankenPHP single binary) that exposes this pattern, so n8n can call it without deploying a full PHP app.
Open questions
- Would the project consider shipping a
docker-compose.yml example for this pattern?
- Is FrankenPHP a reasonable target for a zero-config deployment story?
- Should the microservice handle token generation internally, or require the consumer to pass a pre-generated token?
Use case
We use n8n to orchestrate customer notifications. One step requires sending an SMS via Openapi when a form is submitted. Currently we call a custom PHP endpoint that wraps the SDK, but it feels like unnecessary infrastructure.
Current architecture
The PHP endpoint looks like:
Ideal state
A Docker-composable PHP microservice (or even a standalone FrankenPHP single binary) that exposes this pattern, so n8n can call it without deploying a full PHP app.
Open questions
docker-compose.ymlexample for this pattern?