Scaleway API Connector Guide

The Scaleway API connector lets your Tealfabric workflows call Scaleway services for infrastructure lifecycle and inventory automation. You can use it to create or update cloud resources with send, then fetch current state with receive for approval gates, reconciliation, and reporting.

Document information
FieldValue
Canonical URL/docs/04_connecting-systems/connectors/s/scaleway-api
Version (published date)2026-05-08
Tagsconnectors, reference, scaleway-api
Connector IDscaleway-api-1.0.0

Scaleway API connector flow showing authenticated infrastructure write calls, regional resource retrieval, and workflow-driven cloud operations automation.

Configuration and authentication

Start by configuring organization context and authentication so the connector can access the right Scaleway account. Choose one authentication method per connector configuration to avoid ambiguous credential handling.

  • organization_id (required): Scaleway organization identifier.
  • Authentication (required): either api_token or both access_key and secret_key.
  • base_url (optional): defaults to https://api.scaleway.com.
  • region (optional): defaults to fr-par.
  • timeout_seconds (optional): defaults to 30.

Use scoped credentials with least privilege and rotate keys on a regular schedule. This reduces operational risk while keeping workflow access predictable.

Create resources with send

Use send for provisioning and update flows where your workflow must create or modify Scaleway resources. This example creates a server in a specific zone using the connector execution endpoint.

const baseUrl = "https://api.example.com/api/v1";
const tenantId = "<TENANT_ID>";
const apiKey = "<API_KEY>";

async function createScalewayServer(integrationId: string) {
  const response = await fetch(`${baseUrl}/integrations/${encodeURIComponent(integrationId)}/execute`, {
    method: "POST",
    headers: {
      "X-API-Key": apiKey,
      "X-Tenant-ID": tenantId,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      operation: "send",
      endpoint: "instance/v1/zones/fr-par-1/servers",
      method: "POST",
      data: {
        name: "workflow-web-01",
        commercial_type: "PLAY2-PICO",
        image: "11111111-2222-3333-4444-555555555555",
      },
    }),
  });
  if (!response.ok) throw new Error(`Request failed: ${response.status}`);
  const payload = await response.json();
  return payload.data?.response ?? payload.data;
}
curl -X POST "https://api.example.com/api/v1/integrations/<ENTITY_ID>/execute" \
  -H "X-API-Key: <API_KEY>" \
  -H "X-Tenant-ID: <TENANT_ID>" \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "send",
    "endpoint": "instance/v1/zones/fr-par-1/servers",
    "method": "POST",
    "data": {
      "name": "workflow-web-01",
      "commercial_type": "PLAY2-PICO",
      "image": "11111111-2222-3333-4444-555555555555"
    }
  }'
{
  "success": true,
  "data": {
    "message_count": 1,
    "response": {
      "id": "<ENTITY_ID>",
      "name": "workflow-web-01",
      "state": "starting",
      "zone": "fr-par-1"
    },
    "http_status": 200
  }
}

Retrieve infrastructure data with receive

Use receive when your workflow needs current infrastructure state, such as listing active servers before scaling actions or validating deployment outcomes. Keep query scopes tight to improve response time and reduce API pressure.

const baseUrl = "https://api.example.com/api/v1";
const tenantId = "<TENANT_ID>";
const apiKey = "<API_KEY>";

async function listScalewayServers(integrationId: string) {
  const response = await fetch(`${baseUrl}/integrations/${encodeURIComponent(integrationId)}/execute`, {
    method: "POST",
    headers: {
      "X-API-Key": apiKey,
      "X-Tenant-ID": tenantId,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      operation: "receive",
      endpoint: "instance/v1/zones/fr-par-1/servers",
      query: {
        page: 1,
        per_page: 20,
      },
    }),
  });
  if (!response.ok) throw new Error(`Request failed: ${response.status}`);
  const payload = await response.json();
  return payload.data?.data ?? [];
}
curl -X POST "https://api.example.com/api/v1/integrations/<ENTITY_ID>/execute" \
  -H "X-API-Key: <API_KEY>" \
  -H "X-Tenant-ID: <TENANT_ID>" \
  -H "Content-Type: application/json" \
  -d '{
    "operation": "receive",
    "endpoint": "instance/v1/zones/fr-par-1/servers",
    "query": {
      "page": 1,
      "per_page": 20
    }
  }'
{
  "success": true,
  "data": {
    "message_count": 2,
    "data": [
      {"id": "<ENTITY_ID>", "name": "workflow-web-01", "state": "running"},
      {"id": "<ENTITY_ID>", "name": "workflow-web-02", "state": "stopped"}
    ],
    "total_size": 2,
    "http_status": 200,
    "total_count": 2
  }
}

Operations, testing, and reliability

Besides send and receive, the connector supports sync for paired outbound and inbound behavior and test for connectivity checks against iam/v1alpha1/organizations. For sync, results.outbound and results.inbound contain the same operation payloads returned by standalone send and receive calls (message_count, response or data, http_status, and related fields)—not nested success/data connector envelopes.

For resilient automation, handle authentication failures, 4xx/5xx responses, and rate limits with retries and backoff policies based on operation criticality.

This approach keeps infrastructure workflows observable and predictable as your cloud footprint grows.