# Create a Service Account

In this tutorial, you'll create a dedicated service identity in Synqly for an automated provisioning workflow. The service will be able to create accounts and issue integration tokens using narrowly scoped permissions.

## The scenario

Acme Corp is building **Provisioning Service**, an internal automation that runs whenever a new customer signs up. It must:

1. Create a Synqly account for the customer and label it.
2. Issue a short-lived Integration token once the customer selects a SIEM connector.


This service must operate independently from any human administrator credentials.

## Prerequisites

- A Synqly Organization token with administrator access, available from **[Settings → API Keys](https://app.synqly.com)**. This is used only for setup.
- A tool to make HTTP requests, such as `curl`.


## Step 1: Identify required permissions

Provisioning Service needs two capabilities:

- Create and manage accounts
- Issue integration tokens


These map to the `account-manager` and `token-issuer` permission sets.

While an administrator permission set could also work, it grants more access than this service requires. Narrow permissions reduce risk and make access easier to audit.

## Step 2: Create two roles

Using your Organization token, create two roles scoped only to provisioning resources. Both roles are restricted to accounts labeled `acme-provisioning` in production.

Both roles use the same resource restrictions. This ensures the service can only operate on accounts it is explicitly allowed to manage.

## Step 3: Create the service identity

Create a service account (a Member) for Provisioning Service and bind both roles to it.

This identity now has the combined permissions of both roles,  with the same resource restrictions.

The effective access is the union of both roles, but always constrained by the shared boundary.

## Step 4: Choose how the service authenticates

Provisioning Service needs its own runtime credential. There are two supported approaches:

Service account credential (persistent identity)
Authenticate as the service account to obtain a TokenPair.

This creates a named, auditable identity tied to `svc-provisioning@acme.io`. Access is revoked by disabling or deleting the member.

Use this approach when you want identity tracking and long-lived service ownership.

Scoped organization token (ephemeral credential)
Alternatively, issue a short-lived [Scoped Organization token](/guides/security-model/create-scoped-organization-tokens):

This produces an ephemeral credential that expires automatically. It is useful for scheduled jobs or systems that prefer rotation over persistent identity.

**When using this approach, you do not need to create a service identity (Steps 2 and 3).** The Scoped Organization token is derived directly from your Organization token and carries its own resource restrictions — no Member or role bindings are required.

The `account-manager` permission set is sufficient here. This token is used only for account management operations; it does not issue integration tokens of its own, so the `token-issuer` permission set is not needed.

Both approaches result in the same effective permissions. The difference is lifecycle: one is identity-based, the other is time-bound.

## Step 5: Create the customer account

Using its provisioning credentials, the service creates a new account:

The label is critical. It ensures the account remains within the service's resource restriction and stays manageable by the same roles.

## Step 6: Issue an integration token for the customer

Once the customer selects a SIEM integration, the service issues a short-lived Integration token.

This token is used only by the customer's application to configure the integration. It is separate from the provisioning service's own credentials and is scoped only to the Connector APIs — it does not grant access to the Management APIs.

The customer's application passes this token to the Connector API to perform provider operations:

For more detail on integration token scope and lifecycle, see [Integration Access Tokens](/guides/concepts/integration-access-tokens).

## What you built

You created a dedicated service identity with two narrowly scoped roles, both constrained by the same resource restriction. That identity operates only within the `acme-provisioning` production boundary.

The service can:

- Create and manage accounts it owns
- Issue integration tokens for those accounts


It cannot:

- Access other accounts
- Escalate permissions beyond its roles


This ensures that even if the service is compromised, the impact remains limited to a clearly defined boundary rather than the entire organization.